Einschränkungen in relationalen Datenbanken - Warum nicht vollständig entfernen?

Gibt es heutzutage einen Grund, Einschränkungen zwischen Tabellen (innerhalb von SQL Server) zu erstellen? Wenn ja wann Die meisten Anwendungen in meinem Bereich basieren auf Objektprinzipien und Tabellen werden bei Bedarf zusammengefügt. Die Nachfrage richtet sich nach dem Bedarf der Anwendung. Ich werde nicht eine Reihe von eingeschränkten Tabellen für eine einfache Suche laden, für die wiederum (nach der Aktion) eine einfache Suche erforderlich ist.

ORM-Tools wie EntityContext, Linq2Data, NHibernate behandeln die Einschränkungen auch selbst, zumindest wissen Sie, welche Tabellen einander benötigen. Wenn Sie Einschränkungen innerhalb des Servers vornehmen, müssen Sie dieselben Änderungen nur zweimal vornehmen (erzwingen)?

Dies ist normalerweise keine Entscheidungsfrage, aber diese Datenbank ist ganz anders aufgebaut. Das Design sieht regelmäßig gut aus und spiegelt hauptsächlich die Objekte wider, die von den Anwendungen verwendet werden. Was mich stört, sind alle Einschränkungen, die in SQL Server mit "nicht kaskadieren" konfiguriert sind. Das bedeutet, dass Sie beim Codieren neuer Datenbankabfragen "Suchen und Finden" spielen müssen. In einigen Fällen sind bis zu 10 Ebenen einer genauen Reihenfolge erforderlich, um ein einzelnes Löschen durchzuführen.

Das überrascht mich und ich bin mir nicht sicher, wie ich damit umgehen soll.

In meiner einfachen Welt verlieren die Einschränkungen durch diese Einstellung den größten Teil des Zwecks. OK, wenn Hosts ohne Kenntnis des Designs auf die Datenbank zugreifen.

Wie würden Sie sich in diesem Szenario verhalten?
Warum nicht einfach alle Einschränkungen aus db entfernen und auf Anwendungsebene belassen?

Zwei allgemeine Gründe , um die Kontrakte aus der DB nicht zu entfernen :

• Auf sie können jetzt oder in Zukunft mehr Apps zugreifen , die ORM verwenden oder nicht. Auch wenn die Entwickler dieser Apps alle Einschränkungen genauestens reproduzieren (was bei Nicht-ORM-Lösungen auf niedrigerer Ebene erheblich schwieriger sein kann), ist dies immer ein zusätzlicher Aufwand. Und wenn nicht, reicht schon eine kleine Lücke aus, um die Integrität des Schemas zu brechen ... und das möchten Sie nicht riskieren. In den meisten Unternehmen sind die in ihrer Datenbank gespeicherten Daten das Lebenselixier ihres Geschäfts, daher muss ihre Integrität auf jeden Fall sichergestellt werden. Um dies zu erreichen, müssen so viele Einschränkungen wie möglich in der DB implementiert werden.
• Das Abfrageoptimierungsprogramm stützt sich in hohem Maße auf die auf DB-Ebene bekannten Einschränkungen. Wenn Sie Einschränkungen entfernen, kann sich die Abfrageleistung verschlechtern . Sie werden es vielleicht nicht sofort bemerken, aber eines Tages wird es Sie treffen, und bis dahin könnte es zu spät sein, es einfach zu beheben. Die Natur der Dinge ist, dass die DB-Leistung in der Regel zur Spitzenlastzeit nachlässt, wenn die geringste Möglichkeit besteht, sorgfältige, gut durchdachte Konstruktionsverbesserungen vorzunehmen, die auf genauen Leistungsmessungen und detaillierten Analysen zur Ermittlung der Hauptursachen beruhen.

Ihr konkreter Fall klingt so, als ob das DB-Schema ursprünglich von einem ORM-Tool erstellt wurde (oder von jemandem entwickelt wurde, der mit der relationalen Welt nicht sehr vertraut ist). Aus relationaler Sicht ist es also suboptimal. Es ist wahrscheinlich besser, es zu analysieren und zu verbessern, um ein "natürlicheres" relationales Design zu erhalten, während es mit den ORM-Ansichten konsistent bleibt. Es kann nützlich sein, einen DB-Experten in diese Analyse einzubeziehen.

Anwendungen können kommen und gehen, aber Daten leben für immer. In meiner Firma ist die DB über 30-40 Jahre alt, sie wird so lange weiterleben, wie die Firma existiert. Die Anwendungen ändern sich, Entwickler kommen und gehen. Es ist besser, Integrität und ein gutes logisches Datenmodell zu haben. Auf diese Weise kann sich jemand Daten ansehen und sich ein aussagekräftiges Verständnis verschaffen, ohne eine komplexe Codebasis durchlaufen zu müssen. Dies hilft auch bei der Berichterstattung erheblich. Auch Anwendungen können und werden Fehler aufweisen, und die DB-Einschränkung schützt davor. Meine Standardposition ist es, so viele Einschränkungen (FK und Check) wie möglich zu haben.
Der einzige Grund, keine Einschränkung zu haben, wäre, wenn Ihr Entwurfsmuster dies nicht zulässt, z. B. Tabelle pro Hierarchie oder Leistungsprobleme.

Was mich stört, sind alle Einschränkungen, die in SQL Server mit "nicht kaskadieren" konfiguriert sind.

Das stört mich nicht, das heißt, jemand hat Sinn gezeigt. Kaskadierende Löschvorgänge sind für die Datenbank häufig sehr schlecht. Erstens möchten Sie manchmal, dass das Löschen fehlschlägt, wenn Sie Daten in verknüpften Tabellen haben. Wenn Sie zum Beispiel einen Kunden haben, der in der Vergangenheit einen Auftrag hat, möchten Sie nicht, dass dieser gelöscht wird, oder Sie verlieren die Daten darüber, für wen der Auftrag bestimmt war, und ein Kaskadenlöschvorgang wird den Datensatz beseitigen, der Ihre Finanzberichterstattung durcheinander bringen würde .

Sie scheinen zu denken, dass die Leichtigkeit der Entwicklung das Wichtigste ist. In der Datenbankwelt ist das einfach nicht wahr. Datenintegrität ist das Wichtigste, gefolgt von Leistung und Datensicherheit. Wenn es länger dauert, die Abfragen zu schreiben, dann sei es so.

Auf Datenbanken wird in der Regel von vielen Anwendungen reagiert, dh von einer oder mehreren Websites oder Desktopanwendungen, einer Berichtsanwendung, Webdiensten, dem Abfragefenster, ETL-Prozessen usw. Wenn Sie keine Einschränkungen auf Datenbankebene erzwingen, verlieren Sie zuerst die Integrität der Daten als eine dieser Anwendungen möglicherweise nicht alle Regeln folgen. Zweitens müssen Sie diese Beschränkungen mehrmals codieren und neu schreiben, wenn Sie später eine andere Anwendung verwenden möchten. Drittens können Sie nicht im Voraus steuern, ob eine Datenpflegeaufgabe erforderlich ist, die nicht über die Anwendung ausgeführt wird (z. B. Beheben der Daten aus einem fehlerhaften Kundendatenimport oder Ändern aller 10.000.000 Datensätze von einem Client) an einen anderen Kunden, wenn das Unternehmen von einem Wettbewerber gekauft wird). In der Regel geben Anwendungsentwickler keine

Ich habe irgendwo einmal gelesen, dass grundsätzlich gesagt wird: Die Daten sind der Schlüssel Ihrer Bewerbung . Wenn Sie NIEMALS über Ihre Benutzeroberfläche auf Daten zugreifen (und ich meine, immer , wie jetzt und für immer, für alle Ewigkeit ... oder für die Lebensdauer Ihrer Anwendung), benötigen Sie keine Datenbankeinschränkungen. Es besteht jedoch immer die Möglichkeit, dass etwas anderes als die App selbst Daten berühren muss, z. B. ein Webdienst, eine öffentliche API, eine Rechenaufgabe / ein SQL-Job / ein Cron / ein automatisiertes Skript Straße durch die DB Einschränkungen zu halten.

Ich bin der festen Überzeugung, dass dies der einzige Bereich der Softwareentwicklung ist, in dem Sie DRY nicht anwenden sollten (und ich erwarte eine Reihe von Ablehnungen für diese Aussage). Ihre Daten sind das Herz und die Seele Ihrer Anwendung - wenn sie jemals irreparabel beschädigt wurden, ist das Spiel vorbei. Es lohnt sich IMO, die Einschränkungen überall dort durchzusetzen, wo sie benötigt werden. Wenn dies in Form von Triggern und Einschränkungen auf DB-Ebene, serverseitigen Überprüfungen auf der Middleware und clientseitigem JavaScript auf der Benutzeroberfläche (für Web-Apps) bedeutet, ist es IMO ein notwendiges Übel, um sicherzustellen, dass die Daten immer makellos sind .

Wissen Sie, was ORM bedeutet? Objektrelationale Zuordnung. Zitiert Wikipedia "Technik zum Konvertieren von Daten zwischen inkompatiblen Typsystemen". Ja, relationale und Objektmodelle passen nicht zusammen. ORMs führen eine ziemlich gute Konvertierung durch, indem sie die Regeln beider Typsysteme einhalten. RDBMS sind so organisiert, dass Sie die Datenintegrität mithilfe von Einschränkungen erreichen. Im Allgemeinen ist Integrität eine sehr gute Sache. ORMs verwenden sie daher in der Regel beim Erstellen eines Datenmodells zum Speichern von Objektdaten. Ihr ORM hat wahrscheinlich einen guten Grund, "nicht kaskadierende" Einschränkungen zu verwenden. Und wenn dies Sie dazu zwingt, komplizierte Abfragen durchzuführen, anstatt nur bestimmte Objekte zu erstellen / zu aktualisieren / zu löschen, stimmt etwas nicht mit Ihrem ORM-Setup.

Wenn Sie relationale Konzepte als störend empfinden, warum verwenden Sie dann keine Objektdatenbank? Vor einiger Zeit waren sie langsam (weshalb die meisten Leute immer noch RDBMS verwenden), aber von dem, was ich gehört habe, haben sich die Dinge ein wenig geändert. Sie würden alle relationalen Trottel loswerden. Einfach Objekte rein, Objekte raus.

Genau das hat eBay getan und sie haben wahrscheinlich eine der größten Datenbanken der Welt:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Obwohl oben bereits ausgeführt wurde, dass die Leistung durch referenzielle Integrität erhöht wird, kann sie tatsächlich beeinträchtigt werden. Aus diesem Grund haben massive Datenbanken ihre Einschränkungen aufgehoben und die Arbeit in der Anwendungsschicht erledigt. Und soweit ich das beurteilen kann, ist es der einzige wirklich gute Grund.

Wenn Sie diese Einschränkungen aufheben, verlieren Sie im Wesentlichen Ihr Sicherheitsnetz, das die Daten sauber hält und eigene Probleme mit sich bringt. Es ist also wie bei allem ein Spagat. Ich denke, dass es im Allgemeinen richtig ist, die referenzielle Integrität aufrechtzuerhalten.

Nachdem ich in einer Entwicklungsumgebung mit starker referentieller Integrität gearbeitet habe, weiß ich, dass es aus der Sicht eines Entwicklers ein totaler Schmerz sein kann; In einer Entwicklungsumgebung ist es oftmals unwichtig, ein bisschen schmutzige Daten zu speichern. Das Löschen einer Zeile kann eine Stunde oder länger dauern. Es kann jedoch auch sehr nützlich sein, da die Einschränkungen das Schema explizit machen.

Erstens - meine Antwort: Nein, Sie sollten sich nicht nur auf die Anwendung verlassen, um Ihre Daten zu pflegen.

Dies deutet auf eine größere Debatte hin: ORMs haben eine Kultur der Verachtung für "direkte" DB-Interaktion gefördert, häufig auf Kosten der Normalisierung / referentiellen Integrität. Tabellen werden auf Kosten des im relationalen Modell implizierten Entwurfs zwangsweise auf beliebige Objekthierarchien abgebildet. Die von OOP favorisierte Entkopplung wird hier wohl geopfert, da die Anwendung ihr Design in der Datenstruktur spürbar macht. ORM hat zwar großen Nutzen gezeigt, scheint jedoch auf dem Missbrauch oder Misstrauen von SQL zu beruhen.

Neue Paradigmen tauchen (wieder) auf, zum Beispiel funktionale Programmierung. Wenn sich das Entwicklerteam für eine neue Programmiermethode entscheidet, welche Auswirkungen hat dies dann auf Daten, die gemäß den Anforderungen des ORM strukturiert wurden?

Ich bin mit @Jacek Prucia einverstanden. Ich denke, ORM passt schlecht zu RDBMS. Ich persönlich würde mich für eine DBAL für RDBMS entscheiden oder für eine OODB mit ORM.

Einschränkungen sind Ihre einzige Garantie für Konsistenz und Datenintegrität auf Datenbankebene. Sicher, Sie können Einschränkungen mit Ihrem Anwendungscode erzwingen, aber was ist, wenn Sie die Daten in Zukunft direkt ändern müssen? Möglicherweise wissen Sie, wie Sie die Datenintegrität aufrechterhalten, andere Personen jedoch möglicherweise nicht. Durch Beibehalten der Einschränkungen auf Datenebene wird sichergestellt, dass die Integrität auch dann gewährleistet ist, wenn sich jemand an Orten herumtreibt, die er nicht versteht.

Nehmen wir außerdem an, Ihre Anwendung muss neu geschrieben werden, jedoch mit derselben Datenbank. Alle diese Einschränkungen im Code suchen nur nach Fehlern, die eine Eingabe verhindern und gleichzeitig fehlerhafte Daten zulassen.

Halten Sie es beim Entwickeln einfach. Mit Einschränkungen können Sie das tun. (Das heißt, wenn eine Einschränkung einen Fehler auslöst, spucken Sie nicht denselben Fehler auf den Benutzer zurück. Machen Sie den Fehler verständlich.)

(Zum Kaskadenproblem: Das ist eine gute Sache. Ich würde es vorziehen, einen Fehler zu machen, bei dem bestimmte andere Datensätze zuerst gelöscht werden müssen, anstatt sich auf die Kaskade zu verlassen, um alles richtig zu machen. Kaskaden sind in der Theorie nett, aber nicht unbedingt so in der Praxis.)

Ein Problem mit Einschränkungen in einer Datenbank besteht darin, dass sie dem Programm nur begrenzte Informationen darüber geben, was fehlgeschlagen ist und wie es behoben werden kann. Dies bedeutet, dass es für eine reibungslose Abwicklung häufig erforderlich ist, die Einschränkungsprüfung in der Anwendung zu wiederholen. Daher ist die Datenbank-Einschränkungsprüfung eine Verschwendung von Aufwand.

Dies birgt das Risiko, die Datenintegrität zu gefährden, sodass wir hier Abstriche machen müssen. Bei wichtigen Daten ist die Gewährleistung der Datenintegrität fast immer wichtiger als die Leistung, und es ist weitaus besser, eine Transaktion zu scheitern, selbst wenn sie willkürlich aussieht, als die Daten durcheinander zu bringen.

Um Einschränkungen sicher zu entfernen, ist es daher unerlässlich, den Datenbankzugriff zu sichern, damit nichts die Datenbank ändern kann, ohne die Einschränkungen zu überprüfen. Dies ist nicht zuverlässig, wenn neue Anwendungen geschrieben oder Ad-hoc-Methoden für den Umgang mit den Daten entwickelt werden, da nur ein Fehler erforderlich ist und die Datenbank beschädigt ist.

Um Datenbankeinschränkungen zu umgehen, ist es daher erforderlich, im Vorfeld festzulegen, was mit der Datenbank getan werden kann und was nicht, damit alle Anwendungen ausführlich geschrieben, überprüft und getestet werden können. Alle Datenbankanforderungen müssen im Voraus festgelegt werden, und jede Änderung der Datenbankanforderungen erfordert umfangreiche Arbeiten. Dies ist so etwas wie eine Methode für gefrorene Wasserfälle, die nur in ganz bestimmten Fällen funktioniert. (Das Entwerfen, Implementieren und Einhalten von Anforderungen ähnelt dem Gehen auf dem Wasser. Zuerst muss etwas eingefroren werden, und wenn es nicht ausreichend eingefroren wird, können die Ergebnisse katastrophal sein.)

Ein Fall, in dem es funktioniert, sind die massiven Unternehmensanwendungen wie PeopleSoft und SAP, in denen die Anwendung bereits praktisch alles ausführt, und es gibt sorgfältig definierte Möglichkeiten, sie zu erweitern. Es gibt andere, sehr seltene Möglichkeiten.

Lassen Sie diese Einschränkungen in der Datenbank, es sei denn, Sie arbeiten an einem sehr großen Unternehmensprojekt (und ich möchte es nicht) oder Sie können mit flüssigem Wasser arbeiten.