Generelle Diskussion: Datenbankdesign mit Constraints

Hallo,

ich wollte mal eine generelle Diskussion über das Design von Datenbanken anstoßen. Man kennt das ja aus allen Lehrbüchern. Alle Tabellen sollten eine ID haben die als Primary Key fungiert. Überall schön Constraints und Cascades benutzen. Forein Keys, um die Zusammenhänge zwischen den Tabellen sicherzustellen und es den schicken Tools von Oracle, MS usw. zu vereinfachen schöne ER-Diagramme aus dem DB-Schema zu erstellen. Neulich habe ich aber mit meinem Chef darüber diskutiert. Er hat einige gute Gründe genannt, die gegen die meisten dieser Richtlinien sprechen.

Beispiel: Primary Keys sind zwar schön und gut, aber nur so lange, wie Datenbanken nicht gemerged oder exportiert und wo anders wieder importiert werden müssen. Da bieten Primary Keys nämlich ein schönes Konflikpotential, dass man im Notfall irgendwie auflösen müsste. Schlimmer wird es noch wenn foreign Keys vorhanden sind und die Konflikte sich auf andere Tabellen ausdehnen bzw. plötzlich einfach falsche Referenzen existieren und man die Keys irgendwie anpassen müsste. Statt dessen wäre es doch eigentlich sinnvoller die Schlüssel auf Anwendungsseite in Form von Zeitstempeln o.ä. zu erstellen und gänzlich auf DB-Indizes o.ä. zu verzichten. Von Updates der Schemadefinition und daraus resultierenden Problemen will ich mal gar nicht erst sprechen.

Dahin ist die schöne Theorie des perfekten DB-Designs. Was meint ihr? Wie geht ihr mit diesen Problemen um?

Eine DB ohne PK/FK ist in meinen Augen keine DB sondern nur eine Sammlung sinnloser Tabellen.
Klar die Gründe deines Chefs stimmen schon, aber diese sollte man beim Export beachten. Beispielsweise kann man einfach keine PKs exportieren sondern die Datensätze zusammenfassen.
Und wenn du dann noch sagst du benutzt keine Indizes, dann gute Nacht bei etwas größeren Datenbanken (mehr als 10k Einträge einer Tabelle)

Klar auf Indizes zu verzichten wär ziemlich schlecht, aber Primary bzw. Foreign Keys haben eigentlich keine Vorteile, da ist es doch sinnvoller die Eindeutigkeit von der Anwendungsseite her sicherzustellen. Primary Keys kann man zwar beim Export weglassen, aber Foreign Keys hingegen nicht…

PK/FK haben immer Vorteile, allein schon weil die Anwendung sich nicht um die Integrität kümmern muss. Weil wer sagt das nicht einmal ein Test vergessen wurde? Außerdem denke ich das die Datenbank so einen Test um einiges schneller kann als die Anwendung.

Immer wenn die Datenstruktur verlangt, dass eine Zeile einer Tabelle A ohne eine bestimmte Zeile in einer anderen Tabelle B nicht existieren kann (Composition), dann ist die Datenintegrität mit FK-Beziehung abzusichern. Natürlich macht dies den Import in andere Datenbanken schwieriger. Aber eben auch sicherer. Bei Constraints auf der Datenbank sollte man es natürlich nicht übertreiben. Eine Datenbank muss nicht sicherstellen, dass eine Person kein negatives Alter haben kann, oder dass der Tag der Einschulung nach dem Geburtstag liegt. Sie muss aber sehr wohl sicherstellen, dass die Datenstruktur konsistent ist. Wenn ich beispielsweise in einer BWL-Software eine Tabelle “Angebot”, eine Tabelle “Artikel” und eine Tabelle “Angebotene Artikel” (in der die einzelnen Posten des Angebotes stehen) habe, dann sollte die DB sicher stellen, dass jeder Eintrag in der dritten Tabelle sowohl zu einem Angebot als auch zu einem Artikel passen.

Was die Bildung von PKs angeht: Synthetische Schlüssel sind in aller Regel zu bevorzugen, da sich viele nicht synthetischen Schlüssel im Nachhinein als nicht eindeutig herausstellen. Zum Beispiel kann man annehmen, dass die mathematische Darstellung eines Fingerabdrucks eindeutig ist, bis plötzlich jemand erfolgreich einen Menschen klont. Ein Constraint auf die Eindeutigkeit würde helfen (das könnte man später entfernen), wenn aber alle bezugnehmenden Tabellen das vermeintlich eindeutige Fingerabdruckprofil als Fremdschlüssel verwenden, wird der Änderungsaufwand hoch und die Fehlergefahr bei der Migration groß.

Ebenius

Dazu kommt auch, ein Zahlenwert als Schlüssel ist kleiner als nen Datum oder String. Außerdem lässt er sich besser verarbeiten.