Advanced SQL - Einstiegstutorial 1 - Die Relationen von Angeboten
1. Die Abschnitte
- Vorwort
- Die Modellierung
- Die Standardtabellen
- Die Relationen von Mitgliedern
- Die Relationen von Angeboten
- Feinheiten
2. Auch hier
... noch mal ganz kurz die Relationen der einzelnen Tabellen.
3. Die Tabelle markt
... ist sehr einfach gehalten. Zunächst mal gibt es die obligatorische id
, um den Datensatz eindeutig identifizieren zu können.
Dann haben wir die Spalte besitzer
, in der wir den Gildenmeister verewigen, der eines seiner Mitglieder verschachern will.
Letzteren verewigen wir also in der gleichnamigen Spalte mitglied
. Und zu guter Letzt gibt es preis
, wo die
gewünschte Menge an Gold eingetragen wird.
DROP TABLE IF EXISTS markt;
CREATE TABLE markt
(
id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
besitzer INT UNSIGNED NOT NULL,
mitglied INT UNSIGNED NOT NULL,
preis SMALLINT,
FOREIGN KEY (mitglied) REFERENCES mitglied(id)
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (besitzer) REFERENCES mitglied(id)
ON DELETE CASCADE ON UPDATE CASCADE,
PRIMARY KEY (id)
) ENGINE=INNODB;
4. Die Tabelle angebot
Auch hier gibt es bekanntlicherweise eine mehrfache Relation. Denn ein Gildenmeister (von
) kann einem anderen Gildenmeister
(an
) ein Angebot unterbreiten. Und zwar ein Mitglied (fuer
). Darum steht hier auch drei Mal ein
REFERENCES mitglied(id)
. Die Spalte preis
benötigen wir später.
DROP TABLE IF EXISTS angebot;
CREATE TABLE angebot
(
id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
von INT UNSIGNED NOT NULL,
an INT UNSIGNED NOT NULL,
fuer INT UNSIGNED DEFAULT NULL,
preis SMALLINT,
FOREIGN KEY (von) REFERENCES mitglied(id)
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (an) REFERENCES mitglied(id)
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (fuer) REFERENCES mitglied(id)
ON DELETE CASCADE ON UPDATE CASCADE,
PRIMARY KEY (id)
) ENGINE=INNODB;
Aber!
Warum haben die Spalten von
und an
ein NOT NULL
, während fuer
über ein DEFAULT
NULL
verfügt? Tja, nennen wir es mal vorsichtig eine Designentscheidung. Die Auswirkungen derselben könnt ihr im Moment noch nicht
überblicken. Und mit den Fehlern in dieser Modellierung schlagen wir uns erst bei den Praxistutorials herum.
5. Die Tabelle tausch
... ist die einzige ohne einen Primärschlüssel. Warum? Nun, die nutzen wir für ein Tauschangebot. Da kann ein Gildenmeister einen anderen sagen, "Hey, gib du mir den Troll Üffes und ich bekomme dafür deine Schattenelfe Chantalle. Diese Tabelle wird dann mit dem entsprechenden Angebot aus obiger Tabelle verknüpft.
DROP TABLE IF EXISTS tausch;
CREATE TABLE tausch
(
angebot SMALLINT UNSIGNED NOT NULL,
mitglied INT UNSIGNED NOT NULL,
typ ENUM ('offer','demand'),
UNIQUE KEY (angebot, mitglied),
FOREIGN KEY (angebot) REFERENCES angebot(id)
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (mitglied) REFERENCES mitglied(id)
ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=INNODB;
Ein Hinweis
Macht euch noch keinen großen Kopf um die Relation von tausch
zu angebot
. Das wird erst bei den kommenden Tutorials
eine Rolle spielen. Und was den UNIQUE KEY
angeht, so sei euch nur Folgendes gesagt. Damit verhindern wir schlicht und einfach,
dass in einem(!) Tauschangebot aus Versehen ein Mitglied mehrmals auftauchen kann.
5. So
Jetzt ist unsere Datenbank fertig. "War doch ganz einfach" werden jetzt sicher einige von euch sagen. Ja, weil Papa Kropff euch alles
vorgekaut hat. Aber! Man muss bei Fremdschlüsseln auf wirklich viele Dinge achten, sonst haut es euch je nach MySQL-Frontend eine
Fehlermeldung à la SQL ERROR 1005 Can't create table 'datenbankname.tausch'. Foreign key constraint is incorrectly formed
um die Ohren. Und die Details dazu erfahrt ihr jetzt.
zurück zum vorherigen Abschnitt weiter zum nächsten Abschnitt