Wenn jetzt eine referentielle Integrität dazu kommt, habe ich zwei Stellen, die für die Datenintegrität zuständig sind - für mich sieht das nach Mehraufwand ohne Mehrwert aus.
Wenn du es richtig machst, hast du weiterhin nur eine Stelle, nämlich die Datenbank. Alle Mechanismen, die du in der Anwendung hast, um die referentielle Integrität zu gewährleisten, können dann nämlich weg.
Wenn du dann im Programm einen Fehler einbaust, der die referentielle Integrität verletzt, gibt es eine
Exception. Du kannst also auch nicht ausversehen etwas in der
DB kaputt machen, was dieses Thema betrifft. (Andere Dinge natürlich schon
)
Das Datenbankdesign ist somit vom Programm getrennt!
Ich habe schon in mehreren Firmen gearbeitet, wo auf die referentielle Integrität auf der
DB verzichtet wurde, weil dann einige Dinge "einfacher" gehen. Meine Erfahrung dabei ist, dass das genau nicht der Fall ist. Man muss innerhalb der Programmierung das
DB-Konzept immer im Kopf haben. Je komplexer die
DB wird, desdo größer ist die Fehlergefahr. Es stimmt, dass man z.B. beim Datenimport die Reihenfolge der Tabellen nicht beachten muss, wenn das im Programm verwaltet wird, aber ist es wirklich ein Problem, sowas zu beachten?
Verzichtet man bei der
DB auf Cascading-Delete, kann man manche Datensätze nicht löschen (z.B. 1:n-Beziehungen). Man muss die Reihenfolge beachten und vermeidet dadurch beispielsweise Datenleichen durch Programmabstürze oder Exceptions (ja ich weiß, es gibt auch Transactions). Nutzt man Cascading-Delete, muss man nur den führenden Datensatz löschen. Der Rest wird automatisch mitgelöscht.
Schaut jemand Fremdes auf die
DB (zB mit Auswertungstools), ist durch die referentielle Integrität erkennbar, was wie zusammenhängt.
Das sind natürlich nur kleine Beispiele, aber ich denke, das macht deutlich, warum es sinnvoll sein kann.
Aus meiner praktischen Erfahrung muss ich allerdings auch sagen, dass ich sehr selten sehe, dass die referentielle Integrität auf der
DB tatsächlich eingesetzt wird.