Ihr geht bei euren Erklärungen aus meiner Sicht etwas zu sehr in die (
SQL)Details der Realisierung.
-> Hier geht es doch schlicht um die (derzeit dort wohl fehlende) "Referenzielle Integrität", was für mich die Hauptaufgabe eines
DBMS ist, denn Daten in Tabellen speichern&abfragen, das kann man notfalls auch per
CSV Dateien.
Ein "on delete cascade" wird es in meinen Anwendungen nicht geben. Dort sollen die Exceptions fliegen, wenn wer was zu löschen versucht, was noch anderswo in Benutzung ist.
Wenn überhaupt mache ich das per Triggerfunktion, wo dann StepByStep mit voller Absicht alles einzeln gelöscht wird/werden muss.
Ein "on update cascade" ist bei mir das einzige, was ich "notfalls" im SingeUserMode für Admins zulasse. Es passiert im Alltag, das mal Artikelnummern "auf die schnelle" von irgendwem angelegt werden, aber derjenige übersieht das es eigentlich eine Struktur gibt, wo sagen wir 1xxxyyyyyy doch was anderes ist wie 2xxxyyyyyy... Anwender sind manchmal kreativ beim einbauen und erfinden von eigenen Zusatzregeln... um sowas dann "in einem Rutsch" zu ändern, so das es sich automatisch auf die gesamte
DB auswirkt, egal wo etwas mit diesem Datensatz zu tun hat, genau dafür ist dann ein "on update cascade" brauchbar, aber nicht als Standard. Per Default lasse ich das
DBMS eine Execption schmeißen, wenn jemand versucht "Verknüpfungsdaten" einfach so zu ändern.
Das mal als einfache "Erklärung" ohne viel
DBMS/
SQL Speak, denn ich gebe zu, das ich sowas per Datenbankdesigner-Software und nicht per manuellem
SQL Script erstelle und konfiguriere... Hauptsache ich weiß, warum ich es tue
(ps: so Sachen wie unterschiedliche Schreibweisen funktionieren bei mir mit zusätzlichen Alias-Tabellen in diesem Fall z.B. über PLZ+Vorwahl als Zusatzschlüssel)