Ein ganz wichtiges Kapitel, vorallem wenn es um die Planung eines etwas grösseren Projektes geht, ist das Thema Fremdschlüssel. Fremdschlüssel verbinden (meist tabellenübergreifend) Einträge. Nehmen wir an, wir haben eine “Mitglieder”-Tabelle. Diese Tabelle besitzt die Spalten “id” und “name” wobei ersteres der Primärschlüssel ist:

Nun fügen wir eine weitere Tabelle namens “Tagebuch” hinzu. Sie beinhaltet die Spalten “id”, “mitglied_id” und “eintrag”. Der Primärschlüssel ist “id” und auf “mitglied_id” liegt ein Index:

Der Index ist (je nach DBS) optional aber dringend empfohlen, da es sonst (vorallem mit wachsender Anzahl an Daten) zu starken Geschwindigkeitseinbussen kommen kann. Wir befüllen also die erste Tabelle:

INSERT INTO Mitglieder (id, name) VALUES (42, 'A. Merkel');

und dann noch die zweite:

INSERT INTO Tagebuch (id, mitglied_id, eintrag) VALUES (1, 42, 'I am beautiful, no matter what they say...');

Damit es nicht zur Verwirrung kommt habe ich unserem Mitglied die “id” 42 gegeben. Doch was passiert wenn wir den Eintrag löschen? Nichts. Und genau das ist das Problem: Sobald wir das versuchen würden, müssten wir dafür sorgen dass in allen Untertabellen sämtliche Relationen aktualisiert werden. Da sowas aber je nach Umfang des Projektes sehr kompliziert enden kann, geben die Datenbanksysteme uns eine sehr nützliche Funktionalität:

ALTER TABLE Tagebuch ADD FOREIGN KEY (mitglied_id) REFERENCES Mitglieder(id) ON UPDATE CASCADE ON DELETE CASCADE;

Wir haben soeben erfolgreich einen Fremdschlüssel von “Tagebuch:mitglied_id” zu “Mitglied:id” definiert. Bildlich würde das ganze so aussehen:

Wenn wir jetzt unserem Mitglied eine neue “id” verpassen oder es komplett löschen, geschieht es seinen Tagebucheinträgen gleich. Ausserdem ist es jetzt nicht mehr möglich einen Eintrag mit ungültiger “mitglied_id” in das Tagebuch einzufügen.

Es gibt 5 Reaktionen bei Fremdschlüssel:

** NO ACTION, Verweigert die Änderung und löst ein Fehler aus.
RESTRICT, Verweigert die Änderung und löst ein Fehler aus.
CASCADE, Reagiert gleich wie sein Parent.
SET DEFAULT, Setzt den Standardwert.
SET NULL, Setzt NULL.

** Bei dieser Option ist eine verzögerte Überprüfung möglich um so einer Verletzung der Regel zuvorzukommen.

Information 1: Der Datentyp TEXT gehört nicht zum SQL-Standard. Deshalb wurde VARCHAR ohne Längenangabe verwendet.

Information 2: Das Datenbanksystem MySQL macht keinen Unterschied zwischen “NO ACTION” und “RESTRICT”.

Information 3: Unter MySQL sind Fremdschlüssel nur mit der Datenbankengine InnoDB möglich. Standard: MyISAM.

Jeder kennt es, keiner will es: Race-Conditions. Ein Benutzer registriert sich und versendet versehentlich zweimal hintereinander das gleiche Formular. Wer jetzt zuerst zählt:

SELECT COUNT(*) AS total FROM tabelle WHERE mail = 'user@example.com';

und danach gleich einfügt:

INSERT INTO tabelle (mail) VALUES ('user@example.com');

läuft Gefahr Opfer einer Race-Condition zu werden.

Was ist das und was passiert genau?

Das ist eigentlich ganz einfach erklärt. Wenn wir zweimal das gleiche Formular versenden, durchläuft der Server zweimal die gleiche Datei. Ist der zeitliche Unterschied zwischen den beiden Aufrufen genug klein, ergibt sich bei beiden bei der ersten Zählung 0 und es wird danach auch bei beiden eingefügt. Da Spalten wie “mail” aber üblicherweise einen “unique-constraint” oder eben einen “unique-functional-index” besitzen, kommt es zum schlimmsten: Der spätere der beiden Aufrufe schlägt fehl und wird mit einem Fehler quittiert: Der Datensatz ist bereits vorhanden.

Aber abgebrochene Aufrufe werden vom Server ja auch abgebrochen?

Mit den Standardeinstellungen schon. Oftmals entscheiden sich Programmierer aber dazu “ignore_user_abort” zu benutzen was ja auch seinen guten Grund hat. Beispiel Bilderupload: Dort wird üblicherweise ein SQL-Query versandt und danach die Datei im Dateisystem entsprechend untergebracht. (Das ganze geht auch umgekehrt) Wenn der Benutzer jetzt zwischen einer der beiden Aktionen seinen Aufruf abbricht, haben wir einen losen Datensatz in der Datenbank oder im Dateisystem. Die Integrität wäre verloren. Ein weiteres Beispiel wäre eine Tabelle in der alle Besuche eines Mitglieds bei einem anderen Mitglied gespeichert werden natürlich mit einem “unique-constraint” über from_id und dest_id:

UPDATE tabelle SET visited = NOW() WHERE from_id = 1 AND dest_id = 2;

Wer sich jetzt nur auf die betroffenen Zeilen verlässt und danach gleich einfügt:

INSERT INTO tabelle (from_id, dest_id, visited) VALUES (1, 2, NOW());

hat wieder eine wunderschöne und noch viel wahrscheinlich eintreffendere Race-Condition erstellt. Bei diesem Beispiel reicht es sogar aus ein Mitglied, welches noch nie besucht wurde, zweimal schnell hintereinander (Doppelklick) zu besuchen was ja nun wirklich nicht realitätsfremd ist.

Was kann ich dagegen tun?

Das ist jetzt eben der trickreiche Teil des ganzen. Er nennt sich “INSERT INTO … SELECT” mit einem Subquery und sieht aus wie folgt:

INSERT INTO tabelle (mail) SELECT 'user@example.com' WHERE (SELECT COUNT(*) FROM tabelle WHERE mail = 'user@example.com') = 0;

und für das zweite Beispiel:

INSERT INTO tabelle (from_id, dest_id, visited) SELECT 1, 2, NOW() WHERE (SELECT COUNT(*) FROM tabelle WHERE from_id = 1 AND dest_id = 2) = 0;

Das war es auch schon. Wenn wir jetzt noch sauberkeitshalber die betroffenen Zeilen abfragen, können wir eine schön formatierte Meldung über den (Miss-)Erfolg ausgeben.

Ein Projekt wird realisiert und dabei wird eines viel zu oft vergessen: Die richtige Handhabung der E-Mailadressen. Üblicherweise erstellt der Initiator des Projektes eine Tabelle mit der Spalte “mail”, setzt sie auf unique und gibt sich damit zufrieden. Doch aufgepasst: Je nach Einstellungen des Datenbanksystems oder der Verbindung ist die unique-Spalte case-sensitive. Das bedeutet sie unterscheidet zwischen Gross- und Kleinschreibung. Dann wird es möglich, sich mit ein- und derselben E-Mailadresse mehrmals zu registrieren. Zum Beispiel:

“user@example.com” und “User@example.com”

Ausserdem entfernen die meisten MTAs überschüssige Leerzeichen am Anfang und am Ende der E-Mailadresse.  MTAs (Mail Transfer Agent) sind Programme, die nach dem Aufruf von mail() eine E-Mail im Hintergrund versenden. Ein Beispiel für diesen Fehler:

“user@example.com” und ” user@example.com”

Für die Datenbank sind das nicht die gleichen Strings – für manche MTAs schon. Daraus ergibt sich, vorallem in Kombination beider Fehler, eine imense Anzahl an Möglichkeiten sich mit der gleichen E-Mailadresse zu registrieren.

Nun gibt es grundsätzlich 2 Varianten dem entgegenzutreten. Die erste wäre folgende Funktion:

function address($mail)
{
	$revised = strtolower(trim($mail));
	return $revised;
}

Bei diesem (durch PHP gesicherten) Beispiel muss einfach sichergestellt werden, dass die Funktion überall dort Verwendung findet wo eine E-Mailadresse entgegengenommen wird. Das zweite Beispiel wäre ein sogenannter “functional index” im DBS. Das sind Indizes die einer gewissen Regel (Funktion) obliegen:

CREATE UNIQUE INDEX name_vom_index ON tabelle(lower(trim(spalte)));

Ich bin mir nicht sicher ob MySQL letzteres unterstützt. PostgreSQL tut es zumindest.