Wer benutzt referentielle Integrität / Constraints etc. ?

[Jumpy]

Hallo,

ich möchte die genannte Frage mal unter folgendem Gesichtspunkt in den Raum stellen, da ich das z.Zt. mit meinem Vorgesetzten diskutiere und da mal andere Meinungen hören möchte.

Position 1:
- Ist sinnvoll, da mir (dem Programmierer bzw. dem Programm) so die DB arbeit abnimmt, z.B. Prüfung der Eindeutigkeit einer ID beim Anlegen eines Datensatzes
- Löschweitergabe. Ich muss nur den Hauptdatensatz löschen, die Detaildatensätze werden mitgelöscht.

Position 2:
- Mehr Aufwand beim erstellen der DB
- Wenn die DB z.B. eine PK-Verletzung feststellt, nimmt die den Datensatz nicht an, macht eine Fehlermeldung. Darauf muss der Programmcode reagieren können. Statt das also im Code zu berücksichtigen, kann "ich es auch gleich so programmieren, dass die ID/ das PK-Feld vorher auf Eindeutigkeit geprüft wird". Zumal eine ID ja oft per "nextVal" oder Autowert von der DB kommt.
- Wenn ich das Löschen aus allen Tabellen selber programmiere, weiß ich auch, das es geklappt hat und weiß auch wo ich alles lösche, wenn ich mir später einmal nur den Programmcode angucke, ohne mir auch nochmal die DB angucken zu müssen.

Noch weitere Argumente oder Positionen?

[Nersgatt]

Es sorgt dafür, dass ich als Programmierer schwerer Fehler machen kann, die zur Folge hätten, dass die Daten inkonsistent werden. Das reicht mir schon als Argument, es immer zu benutzen. Gibt nur ganz wenige Ausnahmen, wo ich es nicht mache. Die kann ich an einer Hand abzählen.

[Bernhard Geyer]

Zitat:

Zitat von Jumpy (Beitrag 1122954)

Position 2:
- Mehr Aufwand beim erstellen der DB

Sollte im Verhältnis zum Aufwand/Zeit der das Überlegen/Ausarbeiten eines Vernünftigen DB-Modells hat verschwindent gering sein.

Zitat:

Zitat von Jumpy (Beitrag 1122954)

- Wenn ich das Löschen aus allen Tabellen selber programmiere, weiß ich auch, das es geklappt hat

Hüstel. Wenn ein DBMS das nicht richtig macht dann gehört der Hersteller ganz gewaltig in den Hintern getreten. Wenn sowas nicht klappen würde dann wäre ACID nicht mehr gegeben und man müsste sich überlegen dieses DBMS gar nicht mehr zu unterstützen.

Also in Fast allen Fälle ist das RI/Constraints zu bevorzugen/verwenden.
Einzig für den Fall (womit ich fast immer zu tun habe) wenn man Massendaten für die einzelnen Tabellen unabhängig voneinander bekommt. D.h. Mit neuen Daten für Tabelle "A" löscht man erst alles und importiert sie. Hier wäre es ungünstig wenn eine RI/Constrains alle abhängigkeiten für Tabelle "B", "C", ... löschen würde.

[Phoenix]

Och, es gibt da schon mehr Argumente dafür:

1.) Die Datenbank ist genau für die Einhaltung der referentiellen Integrität da
2.) Dein Programmcode kann Bugs enthalten, und versehentlich doch falsche Daten schreiben. Es ist besser, in diesem Fall eine Fehlermeldung von der Datenbank um die Ohren gehauen zu bekommen als falsche Daten in der Datenbank zu haben.
3.) Punkt 2.) gilt insbesondere, wenn später aufgrund der Daten in der Datenbank Entscheidungen getroffen werden.
4.) Wenn eine Datenbank erstellt wird, plant man die Beziehungen der Tabellen untereinander eh mit, dann ist es nur noch ein kleines mehr an Aufwand, die im Datenbankdesigner auch noch reinzuklicken. Und wenn man noch SQL schreibt ist das auch nicht so furchtbar viel mehraufwand.
5.) Eine Löschweitergabe in der Datenbank ist nicht zwangsläufig notwendig. Man kann das auch manuell machen - auch hier hilft die referentielle Integrität der DB dann aber, fehlerhaftes Löschen zu verhindern (Hauptdatensatz soll gelöscht werden, obwohl noch Referenzen da sind -> Zombie-Datensätze).

Zudem kann die Datenbank über ihr bekannte Beziehungen auch optimieren, was über nicht bekannte Beziehungen eben nicht geht. Das kann zu massiven Performancenachteilen führen, wenn man die Beziehungen nicht korrekt einpflegt.

Das heisst eine korrekt eingerichtete Datenbank ist a) schneller und hilft b) mit, dass Bugs in der Software nicht zu fehlerhaften Daten führen was im schlimmsten Fall zu Fehlentscheidungen, Fehlberechnungen oder zu weiteren Bugs führen kann, weil die Software auf einmal mit fehlerhaften Daten arbeiten müsste.

Andersum gibt es nur einen Grund, eine Datenbank ohne referentielle Integrität aufzusetzen: Man hat keinen Funken Berufsehre und es ist einem egal, wenn man schlampige Arbeit abliefert. Bei mir wäre das abliefern so einer Datenbank ein Grund für eine Abmahnung, wenn nicht sogar für eine fristlose Kündigung.

[DeddyH]

Zitat:

Zitat von Phoenix (Beitrag 1122962)

Andersum gibt es nur einen Grund, eine Datenbank ohne referentielle Integrität aufzusetzen: Man hat keinen Funken Berufsehre und es ist einem egal, wenn man schlampige Arbeit abliefert.

[OT] *Hüstel* es gibt da so ein Framework, wo ich mal locker ein DROP TABLE auf eine Stammdatentabelle loslassen kann (und das natürlich auch ausgeführt wird), ohne dass mich irgendetwas daran hindern würde :zwinker: [/OT]

[Phoenix]

Naja.. das generiert aber dafür auch die kompletten Datenbanken selber :)

[DeddyH]

Ich will das jetzt lieber nicht weiter vertiefen :).

[mkinzler]

Man sollte aber referentielle Integrität nicht mit einer Löschregel gleichsetzen. Eine Datenbank ohne referentielle Integrität macht imho wenig Sinn. Die Einrichtung einer Löschregel ( cascade delete) sollte man sich aber gut Überlegen, da man u.U. da durch einen unbedachten Befehl großen Schaden anrichten kann.

[FredlFesl]

Der einzige 'Nachteil' bei der Implementierung der FK ist der mehr oder minder marginale Performanceverlust. Bei massiven Datenbankoperationen kann sich das schon bemerkbar machen.

Wenn man eh performancetechnisch auf der Kippe steht UND die Anwendung stabil ist, kann man die FK wieder rausschmeissen bzw. die Prüfung deaktivieren.

Ich würde es nicht machen, sondern eher das Design überdenken oder die Hardware aufmotzen.

Was ich oben beschrieben habe ist vergleichbar mit dem Rennfahrer, der sich abschnallt, weil er in extremen Kurvensituationen besser fahren kann und so noch 0.1sec rausholt. Das kann entscheidend sein, aber irgendwie vollkommen bescheuert. Dann lieber seine Fahrkünste und/oder das Auto pimpen.

Ich war allerdings mal in einer Situation (DB-technisch), wo man das Design nicht ändern konnte und für bessere Hardware kein Geld da war. Dann hat das Deaktivieren der Foreign Keys wirklich was gebracht. Wohl war mir dabei allerdings nicht.

Nicht das mich jemand falsch versteht:
DB-Design ohne FK ist was für gehirnamputierte Schwachmaten, Abschalten im laufenden Betrieb eher was für Adrenalinjunkies ;-)

[mkinzler]

Zitat:

Der einzige 'Nachteil' bei der Implementierung der FK ist der mehr oder minder marginale Performanceverlust. Bei massiven Datenbankoperationen kann sich das schon bemerkbar machen.

Aber nur in Sonderfällen. Normalerweise führt der dadurch erzeugte Index zu besseren Performance. (Klar kann man den auch händisch anlegen)