Datenbank Anfängerfrage

[dedlfix]

Tach!

Zu Variante (2) muss man folgendes sagen: Das einzige, was bei meinem Arbeitgeber heiliger ist als die Mittagspause, ist die Performance des Großrechners.

Das ist aber eine eher Einzelsituation. Wenn man diese hat, bekommt man das von den Kollegen, Chefs, Auftraggebern gesagt. Wenn so eine Situation nicht vorliegt, sollte man sich darüber keine Gedanken machen, denn ...

Alle DB-Zusammenhänge hatten sich in Programmlogik wiederzufinden. Das führt dann zwar beim Test gelegentlich zu Inkon(tin|sist)enzen in der DB, aber dafür ist der Test ja da :)

... Konsistenz ist auch ein hohes Gut. Diese in Programmlogik sicherzustellen, erfordert einen hohen Aufwand an Konzentration einerseits, dass man ja keine Vorgänge implementiert, die eine Prüfung unberücksichtigt lassen, oder eben zusätzlicher Maßnahmen wie Tests. Das wird dann schnell mehr Aufwand, als sich mit den Gegebenheiten des DBMS zu befassen. Besonders als Anfänger wird man damit auch so seine Herausforderungen haben.

Andererseites bekommt man das auch hin. Damals, als die InnoDB-Engine noch nicht Standard in MySQL war, sondern MyISAM, und damit die referenzielle Integrität nicht vom DBMS sichergestellt werden konnte, hat man auch Programme mit konsistenter Datenhaltung schreiben können. Das war aber eher aus der Not heraus, nicht etwa weil es vorteilhaft war.

Deswegen: Nutze FKs und Kaskadierung. Das macht das Leben durchaus einfacher. Wenn Du dann allerdings bei DB-Operationen „rumfummeln“ musst, dann müsste die erste Aktion sein, das eigenen DB-Modell und die Funktionsweise der diversen Contraints besser zu verstehen. Wenn Du allerdings auf Situationen stößt, wo Du nicht mehr weißt wie Du mit deinen DB-Operationen um die Constraints herumkommst, musst Du den Sinn der Constraints in Frage stellen.

Kann ich nur unterschreiben.

Manchmal gibt es auch einfach Fälle, wo MYSQL zu dumm ist. Z.B. steht im MYSQL Handbuch unter InnoDB, dass sich diese DB-Engine bei Massenänderungen nicht standardkonform verhält, sie prüft die Contraints zu früh. Dafür gibt's dann zur NOT noch die Option, die Checks abzuschalten, mit SET FOREIGN_KEY_CHECKS=X, mit 0 oder 1 für X. In dem Moment hast Du die Verantwortung für die referenzielle Integrität selbst an der Backe.

Naja, dafür hätte ich als Anwendungsfall nur, wenn man als einmalige administrative Aufgabe, aber nicht im Regelbetrieb, große Datenmengen aus der Datenbank löschen möchte. Zum Beispiel vorinstallierte Demo-Datensätze. Da ist es mitunter recht umständlich, genau die Reihenfolge einzuhalten, in der die Tabellen/Datensätze anzufassen sind, weil ja zuerst alle abhängigen Daten wegmüssen, bevor die Basisdaten gelöscht werden können. Also beispielsweise erst alle Rechnungsposten, dann die Rechnung (falls kein Cascade Delete konfiguriert wurde).

dedlfix.