Was ist mit Datenbankeinschränkungen passiert?

Wenn ich Datenbankmodelle für RDBMS überprüfe, bin ich normalerweise überrascht, keine oder nur geringe Einschränkungen zu finden (abgesehen von PK / FK). Beispielsweise wird der Prozentsatz häufig in einer Spalte des Typs gespeichert int(wobei tinyintdies angemessener wäre), und es gibt keine CHECKEinschränkung, den Wert auf den Bereich 0..100 zu beschränken. In ähnlicher Weise erhalten Antworten auf SE.SE, die Check-Einschränkungen vorschlagen, häufig Kommentare , die darauf hinweisen, dass die Datenbank der falsche Ort für Einschränkungen ist.

Wenn ich nach der Entscheidung frage, keine Einschränkungen zu implementieren, antworten die Teammitglieder:

• Entweder, dass sie nicht einmal wissen, dass solche Funktionen in ihrer Lieblingsdatenbank vorhanden sind. Dies ist nur für Programmierer verständlich, die ORMs verwenden, weniger für Datenbankadministratoren, die angeben, über 5 Jahre Erfahrung mit einem bestimmten RDBMS zu haben.

• Oder dass sie solche Einschränkungen auf Anwendungsebene durchsetzen und diese Regeln in der Datenbank duplizieren, ist keine gute Idee, da sie gegen SSOT verstoßen.

In letzter Zeit sehe ich immer mehr Projekte, in denen nicht einmal Fremdschlüssel verwendet werden. In ähnlicher Weise habe ich hier einige Kommentare zu SE.SE gesehen, die zeigen, dass den Benutzern die referenzielle Integrität nicht sehr wichtig ist und die Anwendung damit umgehen kann.

Bei der Frage nach der Entscheidung, FKs nicht zu verwenden, sagen die Teams Folgendes:

• Es ist PITA, zum Beispiel, wenn man ein Element entfernen muss, auf das in anderen Tabellen verwiesen wird.

• NoSQL rockt und es gibt dort keine Fremdschlüssel. Daher brauchen wir sie in RDBMS nicht.

• In Bezug auf die Leistung ist dies keine große Sache (der Kontext sind normalerweise kleine Intranet-Webanwendungen, die mit kleinen Datenmengen arbeiten, sodass selbst Indizes keine allzu große Rolle spielen; es ist für niemanden wichtig, wenn die Leistung einer bestimmten Abfrage 1,5 Sekunden überschreitet bis 20 ms.)

Wenn ich mir die Anwendung selbst ansehe, stelle ich systematisch zwei Muster fest:

• Die Anwendung bereinigt Daten ordnungsgemäß und überprüft sie, bevor sie an die Datenbank gesendet werden. Beispielsweise gibt es keine Möglichkeit, einen Wert 102als Prozentsatz in der Anwendung zu speichern .

• Die Anwendung geht davon aus, dass alle Daten, die aus der Datenbank stammen, vollständig gültig sind. Das heißt, wenn es 102als Prozentsatz kommt, stürzt entweder irgendwo etwas ab oder es wird dem Benutzer einfach so angezeigt, wie es ist, was zu seltsamen Situationen führt.

• Während mehr als 99% der Abfragen von einer einzelnen Anwendung ausgeführt werden, werden im Laufe der Zeit Skripts angezeigt - entweder Skripts, die bei Bedarf manuell ausgeführt werden, oder Cron-Jobs. Einige Datenvorgänge werden auch manuell in der Datenbank selbst ausgeführt. Sowohl Skripte als auch manuelle SQL-Abfragen bergen ein hohes Risiko, ungültige Werte einzuführen.

Und hier kommt meine Frage:

Was sind die Gründe, relationale Datenbanken ohne Prüfungseinschränkungen und eventuell sogar ohne Fremdschlüssel zu modellieren?

Aufgrund dieser Frage und der erhaltenen Antworten (insbesondere der interessanten Diskussion mit Thomas Kilian) habe ich einen Artikel mit meinen Schlussfolgerungen zum Thema Datenbankbeschränkungen verfasst .

Es ist wichtig, zwischen verschiedenen Anwendungsfällen für Datenbanken zu unterscheiden.

Der Zugriff auf die traditionelle Geschäftsdatenbank erfolgt über mehrere unabhängige Anwendungen und Dienste und möglicherweise direkt durch autorisierte Benutzer. Es ist wichtig, ein durchdachtes Schema und Einschränkungen auf Datenbankebene zu haben, damit ein Fehler oder ein Versehen in einer einzelnen Anwendung die Datenbank nicht beschädigt. Die Datenbank ist geschäftskritisch, was bedeutet, dass inkonsistente oder beschädigte Daten katastrophale Folgen für das Unternehmen haben können. Die Daten bleiben für immer erhalten, während Anwendungen kommen und gehen. Dies sind die Stellen, an denen möglicherweise ein dedizierter DBA vorhanden ist, um die Konsistenz und Integrität der Datenbank sicherzustellen.

Es gibt jedoch auch Systeme, bei denen die Datenbank eng in eine einzige Anwendung integriert ist. Eigenständige Anwendungen oder Webanwendungen mit einer einzigen eingebetteten Datenbank. Solange nur eine einzige Anwendung auf die Datenbank zugreift, könnten Sie Einschränkungen für überflüssig halten - solange die Anwendung ordnungsgemäß funktioniert. Diese Systeme werden häufig von Programmierern entwickelt, die sich auf Anwendungscode konzentrieren und möglicherweise das relationale Modell nicht genau verstehen. Wenn die Anwendung ein ORM verwendet, werden die Einschränkungen möglicherweise auf ORM-Ebene in einer Form deklariert, die den Anwendungsprogrammierern vertrauter ist. Im unteren Ende haben wir PHP - Anwendungen MySQL verwenden, und für eine lange Zeit haben MySQL nicht grundlegende Einschränkungen überhaupt zu unterstützen, so dass Sie hatte auf der Anwendungsebene verlassen Konsistenz zu gewährleisten.

Wenn Entwickler mit unterschiedlichen Hintergründen zusammentreffen, kommt es zu einem Kulturkampf.

In diesem Mix steckt die neue Welle verteilter "Cloud Storage" -Datenbanken. Es ist sehr schwierig, eine verteilte Datenbank konsistent zu halten, ohne den Leistungsvorteil zu verlieren. Daher vermeiden diese Datenbanken häufig Konsistenzprüfungen auf Datenbankebene und ermöglichen es den Programmierern, diese auf Anwendungsebene durchzuführen. Unterschiedliche Anwendungen haben unterschiedliche Konsistenzanforderungen, und während die Googles-Suchmaschine die Verfügbarkeit über die Konsistenz der Server hinweg priorisiert, bin ich bereit, darauf zu wetten, dass das Gehaltsabrechnungssystem auf einer relationalen Datenbank mit vielen Einschränkungen ausgeführt wird.

Heutzutage werden immer mehr Systeme in verteilten Umgebungen in der Cloud ausgeführt und verwenden die Technik des "Skalierens" anstelle des "Skalierens". Dies ist umso wichtiger, wenn Sie mit Anwendungen arbeiten, die mit dem Internet in Verbindung stehen, z. B. mit E-Commerce-Apps.

Davon abgesehen werden alle Anwendungen, die skaliert werden sollen, durch das CAP-Theorem eingeschränkt , bei dem Sie 2 von 3 auswählen müssen: Konsistenz, Verfügbarkeit und Partitionstoleranz (Netzwerkfehlertoleranz).

Wenn Sie sich mit dem CAP-Theorem befassen, werden Sie feststellen, dass es nicht viel Auswahl gibt, sondern Sie entscheiden sich dafür, entweder Verfügbarkeit oder Konsistenz zu verlieren, da Sie NIEMALS 100% der Zeit wirklich auf das Netzwerk vertrauen können.

Im Allgemeinen können es sich mehrere Anwendungen leisten, für einen angemessenen Zeitraum inkonsistent zu sein, sie können es sich jedoch nicht leisten, für die Benutzer nicht verfügbar zu sein. Beispielsweise ist eine leicht ungeordnete Zeitleiste in Facebook oder Twitter besser, als überhaupt keinen Zugriff auf eine Zeitleiste zu haben.

Aus diesem Grund entscheiden sich mehrere Anwendungen für die Aufhebung relationaler Datenbankbeschränkungen, da relationale Datenbanken eine wirklich gute Konsistenz aufweisen, jedoch auf Kosten der Verfügbarkeit.

Persönliche Anmerkung: Ich bin auch altmodisch und arbeite mit einigen wirklich alten Finanzsystemen, in denen Datenkonsistenz die meiste Zeit eine erstklassige Voraussetzung ist und ich ein großer Fan von Datenbankbeschränkungen bin. Die Datenbankeinschränkungen sind die letzte Verteidigungslinie gegen jahrelange schlechte Entwicklung und Entwicklerteams, die kommen und gehen.

"Est modus in rebus". Lassen Sie uns die Konsistenz der Datenbank auf "niedriger Ebene" beibehalten, wo Konsistenz eine erstklassige Anforderung ist. Aber manchmal ist es doch keine große Sünde, es loszulassen.

- BEARBEITEN: -

Da die Frage eine kleine Bearbeitung enthält, gibt es einen weiteren legitimen Grund, Einschränkungen in der Datenbank zu löschen: IMO. Wenn Sie ein Produkt von Grund auf neu entwerfen, bei dem Sie Ihr System für die Unterstützung der Multi-Datenbank-Technologie entwickeln, können Sie sich mit dem kleinsten gemeinsamen Nenner unter den unterstützten Datenbanken zufrieden geben und eventuell die Verwendung von Einschränkungen ganz einstellen, sodass die gesamte Steuerlogik erhalten bleibt Ihre Bewerbung.

Obwohl es legitim ist, ist es für mich auch eine Grauzone, weil ich heute kein Datenbankmodul finde, das einfache Einschränkungen wie die in der ursprünglichen Frage vorgeschlagene nicht unterstützt.

Was sind die Gründe, relationale Datenbanken ohne Prüfungseinschränkungen und eventuell sogar ohne Fremdschlüssel zu modellieren?

Lassen Sie uns zunächst klarstellen, dass ich hier nur über RDBMs spreche, nicht über No-SQL-Datenbanken.

Ich habe ein paar Datenbanken ohne FK oder PK gesehen, geschweige denn Einschränkungen überprüft, aber um ehrlich zu sein, sind sie eine Minderheit. Vielleicht, weil ich in einer großen Firma arbeite.

Nach meiner langjährigen Erfahrung kann ich folgende Gründe nennen:

• Im Falle von Anfängern oder Hobby- Programmierern sollten Sie über Modellierkenntnisse verfügen
• Umfangreiche oder fast ausschließliche Verwendung von ORMs ohne echten Kontakt mit der Datenbankwelt
• Abwesenheit eines DBA oder eines anderen Experten für Datenmodellierung in einem Team oder kleinen Projekt
• Fehlende Einbeziehung des DBA oder des Datenmodellierungsexperten in die ersten Phasen der Entwicklung
• Absichtliche Design - Entscheidungen von einem Teil der Entwickler - Community, die dies auch eine Check - Einschränkung der Auffassung , dass Erzwingt , dass eine bestimmte Spalte nur haben kann , 1,2 or 3als ein Wert, oder dass die „Alter“ Säule sein muss , >= 0ist „Business - Logik in der Datenbank mit“ . Sogar Standardklauseln werden von manchen als Geschäftslogik betrachtet, die nicht zu einer Datenbank gehören, wie Sie in mehreren aktuellen Fragen und Antworten auf dieser Site sehen können. Diese Entwickler, die dies in Betracht ziehen, würden offensichtlich so wenig Einschränkungen wie möglich verwenden und werden alles im Code tun, sogar referenzielle Integrität und / oder Einheitlichkeit. Ich denke, das ist eine extreme Position.
• Verwendung von RDBMs als Schlüsselwertspeicher , entweder zur Emulation des No-SQL-Verhaltens, da die Anforderungen einfach genug waren, um mithilfe von RDBMS-Tabellen als isolierte Schlüsselwert-Repositorys erfüllt zu werden.
• Angenommen, die Datenbank wird immer von "der App" beschrieben, und niemand muss jemals einen massiven Datenladevorgang ausführen oder Zeilen über einen SQL-Client bearbeiten oder einfügen (in vielen Fällen, um fehlerhafte Daten zu korrigieren, die die App eingefügt hat). Im besten Fall gibt es immer eine andere App (neben "der App"), die DML-Anweisungen an die Datenbank ausgibt: einen SQL-Client.
• Keine Ahnung, dass die Daten dem Geschäftsinhaber gehören , nicht der App.

Trotzdem möchte ich festhalten, dass RDBMS sehr fortschrittliche Software sind, die über den Schultern von Riesen entwickelt wurde und sich für viele Geschäftsanforderungen als sehr effizient erwiesen hat und die Programmierer von alltäglichen Aufgaben befreit, die referenzielle Integrität für eine Reihe zu erzwingen von Binärdateien oder Textdateien. Wie ich immer sage "Wir leben nicht länger in einer One-App-One-Database-Welt" . Zumindest ein SQL-Client wird neben "der App" DMLs ausgeben. Die Datenbank sollte sich daher in angemessenem Umfang vor menschlichen Fehlern oder Programmierfehlern schützen

Bei den bekannten Anforderungen, bei denen RDBMS nicht gut skaliert werden kann, wird auf jeden Fall die No-SQL-Technologie eingesetzt . Es ist jedoch besorgniserregend, dass die Verbreitung relationaler Datenbanken ohne Einschränkungen zunimmt, wenn Tausende von Codezeilen (generiert oder typisiert) verwendet werden, um zu erzwingen, was das RDBMS auf effizientere Weise für Sie erzwingen sollte.

Es gibt externe Einschränkungen, die die Technologieentscheidungen bestimmen. Es gibt nur wenige Situationen, in denen Sie die Notwendigkeit und den Luxus haben, Datenbankfeldeinschränkungen regelmäßig zu verwenden.

1. Unternehmen haben Entwickler für Apps und Datenbanken zusammen mit DBA, aber die meisten Entwickler arbeiten nicht in dieser Art von Umgebung. Sie tun so viel wie möglich im Code. Einige auf der Datenbankseite werden auch nicht in die Geschäftsregeln einbezogen. Sie sind in erster Linie dazu da, die Dinge am Laufen zu halten. Sie werden niemals auf Einschränkungen in der Datenbank drängen. Die beste Lösung ist es, ältere Apps, Integrationen, Migrationen, Fusionen und Übernahmen mit einer DB-Einschränkung zu bearbeiten.
2. Durch Überladen der Datenbank kann ein Engpass entstehen, der nicht einfach behoben werden kann, indem mehr Maschinen auf das Problem geworfen werden. Es gibt Situationen, in denen die Sprache db einige Programmierprobleme nicht ohne größere Leistungseinbußen bewältigt. Sie können also nicht planen, für alles eine Einschränkung zu verwenden. Stackoverflow hat einen Datenbankserver, da es eine Herausforderung ist, 2 auf ein Problem zu werfen.
3. Automatisiertes Testen - sie sind da, aber viele Datenbankentwickler kommen mit den IDE / Testing-Frameworks zu spät zur Party.
4. Bereitstellung - mehr Datenbankmaterial macht es komplizierter. Was passiert, wenn eine Aktualisierung der Datenbank eines Clients nicht zulässig ist, weil Daten vorliegen, die die Einschränkung verletzen? Das Spiel ist vorbei, es sei denn, Sie haben eine Möglichkeit, dies zu beheben. In Ihrer App können Sie festlegen, dass der Benutzer dies nach Bedarf handhabt, oder einen Administrator anweisen, dies stapelweise zu tun.
5. Nur die app / api / service schreibt jemals Daten in die Datenbank. Warum also die Mühe machen? Dies hält die meiste Zeit an, weshalb es nicht üblich ist.
6. Der Umgang mit Datenbankfehlern ist schwierig genug, ohne dass Hunderte von Verstößen gegen Beschränkungen zu bewältigen sind, wenn alles aus dem Ruder läuft.

Viele Entwicklungsteams möchten einem Datenbankentwickler nicht zu viel Kontrolle geben. Du hast Glück, wenn du mehr als eine hast, also macht Urlaub viel Spaß. Nicht viele erfordern die absolute Kontrolle über die Datenbankdomäne und übernehmen die Verantwortung für jede Abfrage, Geschäftsregel, Leistung, Verfügbarkeit, Sicherheit und welche Daten in welchem ​​RAID gespeichert werden. Hier sind die gespeicherten Prozeduren, die Sie ausführen dürfen. Habe Spaß. Denken Sie nicht einmal daran, einen Tisch zu berühren.

Dies ist ein Problem, mit dem ich während meiner gesamten Karriere (fast 40 Jahre) und auch beim Schreiben meines DBMS zu kämpfen hatte. Eine Beschreibung meines Endpunkts finden Sie hier: http://unibase.zenucom.com . Also hier sind meine Gedanken.

1. Im Allgemeinen werden die meisten Einschränkungen in der Anwendung besser gehandhabt, sodass verschiedene Teile der Anwendung unterschiedliche Einschränkungen erzwingen können. Beispiel: Ein Landescode ist möglicherweise nicht in allen Ländern gültig.
2. Nebenbei sei vorsichtig mit%. Markups sind> 100% oder Sie gehen pleite :)
3. Einschränkungen lassen sich am besten negativ beschreiben. dh was sie nicht sein können, nicht was sie sein sollten. Es ist immer eine einfachere Liste.
4. Fremdschlüssel sind immer gut und sollten verwendet werden. Punkt. FK ist eines der wenigen semantischen Konstrukte in einem RDBMS und sehr nützlich. Die größte Schwierigkeit besteht darin, zu entscheiden, ob ein Wert baumeln soll, wenn der FK entfernt wird, oder abhängige Zeilen als Grund dafür zu verwenden, den FK-Datensatz nicht zu löschen.
5. Einschränkungen in der realen Welt sind normalerweise komplexer als eine einzelne Feldwerteinschränkung.
6. Einige Einschränkungen, auch auf Anwendungsebene, wirken einem guten Betrieb entgegen. zB versteckt aggressive Datumsprüfung Fehler in scheinbar guten Daten. Sie benötigen einen Bedienerfehler, um ein Maß für Fehler in ansonsten vernünftig aussehenden Daten zu erhalten.

Datenbankbeschränkungen waren vielleicht eine kluge Idee, aber was ist mit einer praktischen Verwendung für sie? Nehmen Sie Ihre prozentuale Einschränkung. Wenn Sie dies anwenden, lehnt Ihre Datenbank ungültige Prozentsätze gerne ab. Und dann? Sie benötigen Geschäftslogik, um die Ausnahme zu behandeln. Was tatsächlich bedeutet, dass die Geschäftslogik, die einen falschen Prozentsatz schreibt, bereits an anderer Stelle fehlgeschlagen ist. Kurz gesagt: Die einzige praktische Einschränkung, die noch besteht, sind die, die Sie sehen (wie PK / FK).

Heutzutage verwenden die Benutzer immer häufiger Software (z. B. Entity Framework), um Tabellen und Spalten automatisch zu generieren. Die Idee ist, dass sie keine SQL-Kenntnisse benötigen, was die Gehirnkapazität freisetzt.

Die Erwartung, dass Software "funktioniert", ist oft unrealistisch und schafft nicht die Einschränkungen, die ein Mensch hätte.

Die besten Ergebnisse erzielen Sie, wenn Sie Tabellen mit SQL erstellen und Einschränkungen manuell hinzufügen. In einigen Fällen ist dies jedoch nicht möglich.