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.