Referentielle Integrität - notwendig oder nice to have?

[ggscholz]

Hallo in die Expertenrunde,

in den Lehrbüchern zu SQL wird immer auf die referentielle Integrität hingewiesen, um die Datenintegrität zu sichern.

Bisher habe ich darauf verzichtet. Die zu meinem Program gehörende DB wird nur von meiner Anwendung benutzt, 'hintenrum' geht's nur, wenn ich als Programmierer irgendetwas ändern möchte.

Ich bin also bisher verantwortlich, das die Anwendung in der Datenbank nichts durcheinander bringt. 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.

Gibt es gewichtige Gründe, über Fremdschlüssel die Datenintegrität zu sichern? Werden z.B. Selects schneller in der Ausführung?

Bin gespannt auf eure Antworten!

Beste Grüße

Gerd

[peterbelow]

Zitat:

Zitat von ggscholz (Beitrag 1531667)

Hallo in die Expertenrunde,

in den Lehrbüchern zu SQL wird immer auf die referentielle Integrität hingewiesen, um die Datenintegrität zu sichern.

Bisher habe ich darauf verzichtet. Die zu meinem Program gehörende DB wird nur von meiner Anwendung benutzt, 'hintenrum' geht's nur, wenn ich als Programmierer irgendetwas ändern möchte.

Ich bin also bisher verantwortlich, das die Anwendung in der Datenbank nichts durcheinander bringt. 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.

Gibt es gewichtige Gründe, über Fremdschlüssel die Datenintegrität zu sichern? Werden z.B. Selects schneller in der Ausführung?

Bin gespannt auf eure Antworten!

Beste Grüße

Gerd

Mach es in der Datenbank und Du kannst sicher sein, dass die Daten konsistent bleiben, egal wer und wie darauf zugreift. Das ist simples "future proofing"; auch wenn es momentan nur diese eine Anwendung gibt und nur einen Benutzer: verwendest Du niemals eines der Datenbank-Tools, die mit dem DB Server geliefert werden? Keine SQL-Scripte, keine Änderungen in der Tabellenstruktur, keine "manuellen" Korrekturen von Eingabefehlern? Wirst Du nicht irgendwann mal eine anderes Interface für die Datenbank schreiben (müssen)? Web, Android App?

[Jasocul]

Zitat:

Zitat von ggscholz (Beitrag 1531667)

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 :wink:)
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.

[himitsu]

Außerdem gibt es für die Referenzen automatisch ein paar Indize (ja, die könnte man auch so manuell erstellen)
und damit gehen SELECT+WHERE/JOIN auf diese Felder natürlich wesentlich schneller.

[ggscholz]

Dann mal vielen herzlichen Dank für die deutlichen und (wie immer hier!!) ausführlichen Hinweise, mich nicht um die referentielle Integrität zu drücken.

Ist am Ende ja auch kein Hexenwerk. Aber auf jeden Fall erstmal aufwendiger.

Beste Grüße

Gerd

[Delphi.Narium]

'nen Überblick über Constraints unter Postgres findest Du hier Documentation → PostgreSQL 16

Viele Constrains sind datenbankseitig schlichte Einzeiler.

Das bekommst Du (höchstwahrscheinlich / vermutlich) mit keiner Programmiersprache der Welt ähnlich kurz implementiert.

Das

Zitat:

Zitat von ggscholz

Aber auf jeden Fall erstmal aufwendiger.

trifft von daher eher nur dann zu, wenn man die datenbankseitige Lösung erst später in die Datenbank einbaut, statt sie beim Design der Datenbank von vorneherein mit einzuplanen und umzusetzen.