Hauptmenü

Untermenü

Advanced SQL - Einstiegstutorial 1 - Die Relationen von Angeboten

1. Die Abschnitte

2. Auch hier

... noch mal ganz kurz die Relationen der einzelnen Tabellen.

Relation angebot

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 (mitgliedREFERENCES mitglied(id)
    ON DELETE CASCADE ON UPDATE CASCADE,
  FOREIGN KEY (besitzerREFERENCES 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 (vonREFERENCES mitglied(id)
    ON DELETE CASCADE ON UPDATE CASCADE,
  FOREIGN KEY (anREFERENCES mitglied(id)
    ON DELETE CASCADE ON UPDATE CASCADE,
  FOREIGN KEY (fuerREFERENCES 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 (angebotmitglied),
  FOREIGN KEY (angebotREFERENCES angebot(id)
    ON DELETE CASCADE ON UPDATE CASCADE,
  FOREIGN KEY (mitgliedREFERENCES 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