Advanced MySQL - Referentielle Integrität

1. Das altbekannte Problem

So, nehmen wir jetzt mal die (stark vereinfachte) Datenbank einer Firma, wo es um Gehaltszahlungen geht.

Tabelle Mitarbeiter  Tabelle Konto       Tabelle Überweisung
+--+-------+------+  +----+----+------+  +----+----------+------+
|id|vorname|name  |  |m_id|blz |kto_nr|  |k_id|datum     |betrag|
+--+-------+------+  +----+----+------+  +----+----------+------+
| 1|Peter  |Kropff|  |   1|1234|154762|  |   1|2011-08-01|  3000|
+--+-------+------+  +----+----+------+  +----+----------+------+
| 2|Jochen |Bla   |  |   2|4567|845677|  |   2|2011-08-01|  3000|
+--+-------+------+  +----+----+------+  +----+----------+------+
| 3|Michael|Blubb |  |   3|9876|549661|  |   3|2011-08-01|  3000|
+--+-------+------+  +----+----+------+  +----+----------+------+

Die Relation ist einfach zu erklären. m_id der Tabelle Konto verweist auf id von Mitarbeiter. Und k_id von Überweisung bezieht sich auf m_id von Konto. Ach ja, nehmt das mit den 3000 netto nicht ernst. Soviel verdiene ich nicht. Oder genauer gesagt, soviel bekomme ich nicht. Verdient hätte ich es schon. ;-)

2. Fehlerquellen

Wie ihr sicher schon wisst, gibt es hier bei MyISAM-Tabellen in der MySQL-Normalkonfiguration einige möglich Fehlerquellen. Und die schauen wir uns mal genauer an.

Relationen zerstören

Null problemo, man löscht einfach irgendwo einen Eintrag und schon gibt es einen logischen Bruch in der Datenbank. Nehmen wir einfach mal ein paar Möglichkeiten.

• In der Tabelle Konto wird ein Eintrag gelöscht. Dann bekommt der Mitarbeiter kein Geld.
• Man löscht einen Mitarbeiter, dann lümmeln sich ein paar Datensätze herum, die keinen Bezug mehr zum Ursprung haben.
• Aus der Tabelle Überweisung wird ein Eintrag gelöscht, dann kommt die Buchhaltung durcheinander.

Fehlerhafte Eingaben

Auch hier gibt es einige Möglichkeiten, die für Ärger sorgen können. Nehmen wir mal, die Person aus der Buchhaltung tippt beim Gehalt eines Mitarbeiters anstelle der 3000 aus Versehen ein 3ooo ein. Dann bekommt die arme Sau nur 3 Öcken (wegen der drei kleinen Os). Oder besagte Person hat ihre Finger nicht im Griff und macht aus der 3000 eine 30000. Schön für den Kollegen, schlecht für die Firma.

Ein weiterer Fehler wäre die falsche Angabe des Abbuchungsdatums. Wenn man da Murks bei der Eingabe macht, steht da auf einmal ein 0000-00-00 und der betroffene Mitarbeiter wartet bis zum Sankt Nimmerleinstag auf seine Kohle.

Fehler bei der Überweisung

Selbst wenn alle Daten korrekt eingegeben wurden, so ist eine Überweisung immer noch eine sehr heikle Sache, da es da um das liebe Geld geht. So könnte es passieren, dass der Betrag zwar abgebucht wird, aber nicht beim Empfänger ankommt. Das ist schlecht für die Firma und den betroffenen Kollegen.

3. Folgerungen

Für eine tipptopp saubere Datenbank müssen also folgende Kriterien gelten.

• Die Relationen müssen erhalten bleiben.
• Eingaben, die dem Typ der Spalte nicht entsprechen, dürfen nicht vorgenommen werden.
• Änderungen an "sensiblen" Tabellendaten dürfen nur nach dem Prinzip "alles oder nicht" durchgeführt werden.

4. Lösungsmöglichkeiten

Nun, bei den fehlerhaften Eingaben hilft uns der Strict-Modus von MySQL auf die Beine. Was die Relationen und Probleme bei Überweisungen angeht, das lässt sich nur mit Tabellen vom Typ InnoDB lösen.

zurück zum vorherigen Abschnitt weiter zum nächsten Abschnitt