Was ist mit Datenbankeinschränkungen passiert?

46

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 .

Arseni Mourzenko
quelle
8
Ich fühle für dich, aber es scheint, dass du bereits weißt, warum Einschränkungen eine gute Idee sind. Es gibt also nicht viel hinzuzufügen in Form einer Antwort. Ich werde jedoch bemerken, dass das Fehlen von Einschränkungen kein neues Phänomen ist. Ich habe es jahrzehntelang in Datenbanken gesehen, die von Entwicklern ohne ein starkes Verständnis relationaler Datenbanken entworfen wurden. Ich denke, es ist selten eine bewusste Designentscheidung.
JacquesB
1
@JacquesB: Sie können eine Antwort posten, da "Ich habe es seit Jahrzehnten gesehen" eine ganz andere Sichtweise gibt als die, die ich von einem Phänomen hatte, das vor drei bis vier Jahren auftrat (da ich weniger als ein Jahr in der IT gearbeitet habe) Jahrzehnt ist meine Ansicht über das Phänomen wahrscheinlich falsch). Daher wären auch die Schlussfolgerungen sehr unterschiedlich.
Arseni Mourzenko
1
Wir arbeiten mit vielen Kunden zusammen. Und während die Einführung einer neuen Version unserer Software ein Kinderspiel ist, ist die Aktualisierung aller Datenbanken überall ein Problem. Aus diesem Grund haben wir die meisten Einschränkungen bei der Software. Oh ja, ein winziger Prozentsatz ist oft keine gute Idee, weil Prozentsätze Brüche sein können.
Pieter B
1
Abstimmung, um diese Frage erneut zu eröffnen, da sie fälschlicherweise als "hauptsächlich meinungsbasiert" geschlossen wurde, wenn die bisherigen Antworten zeigen, dass dies nicht der Fall ist.
David Arno
3
Ich bin zu 110% bei dir.
Periata Breatta

Antworten:

28

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.

JacquesB
quelle
5
+! 1 für die Erwähnung des Elefanten im Raum: die falsche Annahme, dass eine Anwendung nur eine
Datenbank
4
@ TulainsCórdova, ich dachte, der Elefant im Raum hier wäre Googles Gehaltsabrechnungssystem. :)
Machado
5
@Machado Das ist Genie: "Ich bin bereit zu wetten, dass ihr Gehaltsabrechnungssystem auf einer relationalen Datenbank mit vielen Einschränkungen läuft."
Tulains Córdova
2
Es ist auch praktisch, Datenbanken mit angemessenen Einschränkungen zu haben, da Ihr Anwendungscode nicht ACID ist.
Matthew Whited
3
Um den Kommentar von @MatthewWhited hervorzuheben, ist es für Anwendungen nicht möglich, bestimmte Arten von Einschränkungen zwischen Zeilen und Tabellen zu erzwingen, ohne Sperren durchzuführen und zusätzliche Abfragen auszuführen. Ein RDBMS kann dies zu viel geringeren Kosten tun.
David Aldridge
15

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.

Machado
quelle
"Ich kann heute einfach keine Datenbank-Engine finden, die einfache Einschränkungen wie die in der ursprünglichen Frage vorgeschlagene nicht unterstützt." Unterstützt MySQL noch CHECK-Einschränkungen?
Vincent Savard
@VincentSavard, vielleicht nicht die exakte CHECK MS SQL, aber irgendeine Einschränkung: dev.mysql.com/doc/refman/5.7/en/constraint-invalid-data.html
Machado
@Machado - hier geht es jedoch nicht nur um bestimmte Einschränkungen, sondern auch darum, festzustellen, wann Abfragen Daten enthalten, die nicht in den entsprechenden Typen dargestellt werden können. Das ist eine deutliche Verbesserung gegenüber der Situation vor Jahren, als MySQL solche Werte einfach stillschweigend ignorierte.
Periata Breatta
1
@PeriataBreatta, abgesehen davon habe ich nie ganz verstanden, warum MySQL die von Website-Entwicklern gewählte "De-facto" -OSS-Datenbank war, als PostgreSQL vollständig verfügbar und weiter fortgeschritten war. Vielleicht war es einfacher zu installieren, ich weiß es nicht.
Machado
@machado - Ich kann nicht sicher sein , aber ich weiß, dass ich in den frühen Tagen (Mitte der 90er Jahre) dazu neigte, MySQL Postgres vorzuziehen (das erst später in Postgresql umbenannt wurde), weil dieses Postgres falsch verstanden wurde SQL wurde nicht unterstützt (die frühen Versionen hatten keine - es hatte eine eigene Abfragesprache namens "postquel" - und ich war mit der Entwicklung nicht auf dem neuesten Stand und hatte nicht bemerkt, dass sie bei ungefähr SQL-Unterstützung hinzugefügt haben zur gleichen Zeit wurde MySQL verfügbar). Wenn dieses Missverständnis weit verbreitet war, ist es möglich, dass mysql nur deswegen weiterkam. Und als es soweit war, übernahmen die Netzwerkeffekte.
Periata Breatta
10

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.

Tulains Córdova
quelle
3

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.

JeffO
quelle
2

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.
Rick Marshall
quelle
1

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).

qwerty_so
quelle
15
Ich bin damit höflich nicht einverstanden. Wenn Sie wirklich Datenkonsistenz benötigen, sind DB-Einschränkungen ein Muss, insbesondere wenn Ihre Geschäftslogik ausfällt. So, wie Sie das Szenario beschreiben, würde ein stiller Fehler auftreten, bei dem der durch einen falschen Prozentsatz an Fehlern verursachte Schaden sich im System weiter ausbreitet. Wenn Sie diesbezüglich eine DB-Einschränkung haben, würden Sie schnell versagen und den Geschäftslogik-Entwicklern somit die Möglichkeit geben, den Fehler frühzeitig zu erkennen und das Geschäftslogik-System zu patchen, anstatt beschädigte Daten darin zuzulassen.
Machado
5
Nach meinem Verständnis müssen Sie diese Ausnahme nicht behandeln , wenn eine prozentuale Beschränkung verletzt wird , da eine solche Verletzung darauf hinweist, dass in Ihrem Code ein Fehler vorliegt (entweder hat jemand eine einfache Ganzzahl anstelle einer PercentageKlasseninstanz verwendet, oder es liegt ein Fehler in der Validierung selbst vor), im Gegensatz zu einem Ausnahmefall (z. B. wenn eine Netzwerkverbindung unterbrochen ist). Für mich sollte der Verstoß zu HTTP 500 für eine Web-App oder einem Absturz für eine Desktop-App führen und dann protokolliert und behoben werden.
Arseni Mourzenko
7
@ ThomasKilian: nein; genau das Gegenteil. Die falschen Daten werden nicht eingehen, insbesondere weil Datenbankeinschränkungen vorhanden sind. Wenn Ihre Geschäftslogik im Code richtig ist, werden Sie diese Einschränkungen niemals verletzen. Wenn im Code ein Fehler aufgetreten ist, werden Sie durch diese Einschränkungen auf diesen Fehler aufmerksam gemacht, und die Datenbank wird vor dem Verschrotten geschützt.
Arseni Mourzenko
9
@ThomasKilian: Ich glaube nicht, dass irgendjemand dagegen argumentiert, "es von Anfang an richtig zu machen" - es ist wahrscheinlich eher so, dass jeder mit ein bisschen Erfahrung weiß, dass es eine schlechte Idee ist, ein System unter der Annahme zu entwerfen, dass Sie es tun werden bekommen alles gleich beim ersten Mal und keine Bugs oder Fehler werden immer während der Lebensdauer des Systems auftreten. DB-Einschränkungen stellen sicher, dass ein Fehler die Datenbank nicht beschädigt.
JacquesB
3
@JacquesB Ich kämpfe gegen Windmühlen. Wenn Sie Geschäftslogik in die Datenbank einfügen, kann dies ebenso fehlschlagen wie an erster Stelle und Sie werden nicht auf die gleiche Weise gespeichert. Aber (!) Sie haben jetzt Geschäftslogik, wo sie nicht hingehört. Zu glauben, dass die DB Ihre faule Geschäftslogik retten kann, ist einfach falsch. Die Logik in der DB muss den gleichen Regeln wie die gesamte Geschäftslogik folgen.
qwerty_so
1

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.


quelle
Natürlich unterstützen einige Frameworks das automatische Hinzufügen von PKs und FKs (semi).
David Aldridge