Advanced SQL - Einstiegstutorial 1 - Die Relationen von Mitgliedern
1. Die Abschnitte
- Vorwort
- Die Modellierung
- Die Standardtabellen
- Die Relationen von Mitgliedern
- Die Relationen von Angeboten
- Feinheiten
2. Die Abhängigkeiten
... habe ich euch ja schon beim Abschnitt Modellierung gezeigt. Schauen wir uns das trotzdem noch mal an.
3. Die Tabelle charakter
Ein Charakter setzt sich aus einem Wesen und einer Erfahrungsstufe zusammen. Hinzu kommt noch, dass er (oder sie) über eine bestimmte Menge an Gold verfügt. Damit beschäftigen wir uns aber erst bei den kommenden Tutorials. Der Aufbau sieht also so aus.
DROP TABLE IF EXISTS charakter;
CREATE TABLE charakter
(
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
wesen TINYINT UNSIGNED,
stufe TINYINT UNSIGNED,
gold SMALLINT UNSIGNED,
FOREIGN KEY (wesen) REFERENCES wesen(id)
ON DELETE RESTRICT ON UPDATE CASCADE,
FOREIGN KEY (stufe) REFERENCES stufe(id)
ON DELETE RESTRICT ON UPDATE CASCADE,
PRIMARY KEY (id)
) ENGINE=INNODB;
Erläuterung
Die id benötigen wir, um einen Charakter später einen Spieler eindeutig zuordnen zu können. Weil wir in unserem Spiel
mit vielen Möglichkeiten rechnen müssen, arbeiten wir hier mit einem INT. Bei den "Relationsspalten" stufe
und wesen übernehmen wir die Werte der jeweiligen id aus den entsprechenden Tabellen.
Die Fremdschlüssel
Das ist eigentlich eine logische Sache. Die Spalte wesen verweist auf id der Tabelle wesen
und stufe auf id der Tabelle stufe.
ON DELETE
Nun, hier geht es einfach nur um eine Entscheidung. Also wie geht man damit um, wenn das "Elternelement" gelöscht wird? Darum
entscheiden wir uns hier generell für ein RESTRICT, denn dann kann man aus der Elterntabelle keinen Eintrag löschen, wenn
die ID auf ein Kindelement verweist.
ON UPDATE
Diese Entscheidung liegt auf der Hand. Ändert man aus Versehen die id eines entsprechenden Tabelleneintrages, so wird das
hier automatisch angepasst.
4. Die Tabelle mitglied
Auf die Details werde ich nicht mehr großartig eingehen, die sind ähnlich wie bei der Tabelle charakter. Der Aufbau stellt
sich dann wie folgt dar.
DROP TABLE IF EXISTS mitglied;
CREATE TABLE mitglied
(
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
name VARCHAR(128),
gilde SMALLINT UNSIGNED,
charakter INT UNSIGNED,
status ENUM('1','2'),
login varchar(64),
pw varchar(255),
UNIQUE KEY (login),
UNIQUE KEY (pw),
UNIQUE KEY spieler (name, gilde, charakter),
FOREIGN KEY (gilde) REFERENCES gilde(id)
ON DELETE SET NULL ON UPDATE CASCADE,
FOREIGN KEY (status) REFERENCES status(id)
ON DELETE RESTRICT ON UPDATE CASCADE,
FOREIGN KEY (charakter) REFERENCES charakter(id)
ON DELETE CASCADE ON UPDATE CASCADE,
PRIMARY KEY (id)
) ENGINE=INNODB;
Erläuterung
Die Fremdschlüssel
Hier gehen wir einen anderen Weg. Bei der Spalte gilde setzen wir beim ON DELETE ein SET NULL.
Ist also die Gilde weg, gibt es keine Zuordnung mehr.
Den Erfahrungsstatus wollen wir aber behalten (warum ist erst mal egal), also nehmen wir beim ON DELETE das schon bekannte
RESTRICT. Ganz rabiat gehen wir bei der Spalte charakter vor. Wird der gehimmelt, dann verabschiedet sich
unser Mitglied ebenfalls in die ewigen Jagdgründe. Denn genau das passiert mit dem ON DELETE CASCADE.
UNIQUE KEY
Zunächst mal vergeben wir zwei einzigartige Schlüssel für login und pw. Die benötigen wir später für die
Anmeldeprozedur. Dann bauen wir uns einen UNIQUE KEY zusammen, der aus drei Spalten besteht, name,
gilde und charakter.
Und was soll das?
Ganz einfach. So haben die Mitglieder der einzelnen Gilden viel mehr Freiheiten, sich einen Charakter zusammenzustellen. Es kann also zum Beispiel mehrere Kampfzwerge namens Fluppiwuppi und Homöopathiezauberer mit demselben Namen geben. Die dürfen nur nicht in der eigenen Gilde sein. Klingt vielleicht jetzt komisch, aber hier geht es nicht ums Zocken, sondern ums Lernen.
zurück zum vorherigen Abschnitt weiter zum nächsten Abschnitt