Sollen Geschäftsregeln sowohl in der Anwendungsschicht als auch in der Datenbankstufe durchgesetzt werden, oder nur eine der beiden?

Question

Ich habe Geschäftsregeln sowohl in meiner Anwendungsebene (Modelle) als auch in meiner Datenbankebene durchgesetzt (gespeicherte Prozeduren, die Fehler auslösen).

Ich habe meine Validierungen in beiden Orten für ein paar Gründe zu duplizieren:

1. Wenn die Bedingungen zwischen ändern, wenn sie in dem Anwendungscode überprüft werden, und wenn sie in der Datenbank überprüft, Die Geschäftsregelüberprüfungen in der Datenbank speichern den Tag. Die Datenbank ermöglicht es mir auch verschiedene Datensätze in einer einfacheren Weise als in meinen Anwendungscode zu sperren, so scheint es natürlich hier zu tun.
2. Wenn wir haben einige Chargendaten Einfügungen/Aktualisierungen der Datenbank direkt zu tun, wenn ich Route alle diese Operationen durch meine gespeicherten Prozeduren/Funktionen, die die Geschäftsregel Validierungen tun, gibt es keine Chance, mich schlechte Daten, obwohl mir die Schutzmaßnahmen fehlen, die ich bekommen würde, wenn ich Single-Input durch die Anwendung machen würde.
3. Während diese Dinge nur in der Datenbank Durchsetzung den gleichen Effekt auf den tatsächlichen Daten hätte, so scheint es ungeeignet nur Daten auf der vor Datenbank wirft zunächst eine gute Mühe, zu überprüfen, ob es entspricht zu Einschränkungen und Geschäftsregeln.

Was ist die richtige Balance?

Answer 1

Sie müssen auf der Datenebene erzwingen, um die Datenintegrität sicherzustellen. Das ist Ihre letzte Verteidigungslinie, und das ist der Job der DB, um seine Weltansicht der Daten durchzusetzen.

Das heißt, werfen Junk-Daten gegen die DB zur Validierung ist eine grobe Technik. In der Regel sind die Fehler so gestaltet, dass sie für Menschen lesbar und nicht maschinenlesbar sind. Daher ist es für das Programm ineffizient, den Fehler aus der DB zu verarbeiten und daraus Kopf- oder Zahlfehler zu machen.

Gespeicherte Prozeduren sind eine andere Sache. Damals waren Stored Procedures der Weg, um Geschäftsregeln auf den Datenebenen usw. zu handhaben.

Aber heute, mit den modernen Anwendungsserver-Umgebungen, haben sie sich im Allgemeinen zu einem besseren Ort entwickelt, um diese Logik umzusetzen. Sie bieten mehrere Möglichkeiten, auf die Daten zuzugreifen und sie verfügbar zu machen (Web, Webdienste, Remote-Protokolle, APIs usw.). Wenn Ihre Regeln CPU-lastig sind (wohl die meisten nicht), ist es einfacher, App-Server als DB-Server zu skalieren.

Die große Auswahl an Funktionen innerhalb der App-Server gibt ihnen eine Flexibilität, die über die Möglichkeiten der DB-Server hinausgeht. Daher wird viel von dem, was einmal in die DBs zurückgeschoben wurde, mit den DB-Servern herausgezogen. dumme Persistenz ".

Das heißt, es gibt sicherlich Leistungsvorteile mit Stored Procs und so, aber jetzt ist das eine Tuning-Sache, wo die Frage wird "ist es wert, die App-Server-Fähigkeit für den Gewinn zu verlieren, indem wir es in den DB-Server ".

Und von App-Server, ich spreche nicht nur Java, aber .NET und sogar PHP usw.

Answer 2

Ihre Geschäftslogik in beiden Orten sitzen können, sollte aber nicht in beiden. Die Logik sollte NICHT dupliziert werden, da es leicht ist, einen Fehler zu machen, wenn man versucht, beide synchron zu halten. Wenn Sie es in das Modell einfügen, möchten Sie, dass der gesamte Datenzugriff Ihre Modelle durchläuft, einschließlich Stapelaktualisierungen.

Es wird Kompromisse sei es in der Datenbank gegen die Anwendungsmodelle zu setzen (hier ein paar der Spitze von meinem Kopf):

• Datenbanken können schwieriger zu pflegen und zu aktualisieren als Anwendungen
• es ist leichter Last zu verteilen, wenn es in der Anwendungsebene ist
• Mehrere, unterschiedliche dbs Regeln Splitting Unternehmen erfordern kann (was nicht möglich sein kann)

Answer 3

wenn die Regel sein muss jederzeit durchgesetzt, unabhängig davon, woher die Daten stammen oder wie sie aktualisiert wurden, ist die Datenbank da, wo sie sein muss. Denken Sie daran, dass Datenbanken von direkten Abfragen betroffen sind, um Änderungen vorzunehmen, die sich auf viele Datensätze auswirken oder etwas tun, was die Anwendung normalerweise nicht tun würde. Dies sind Dinge wie das Reparieren einer Gruppe von Datensätzen, wenn ein Kunde von einem anderen Kunden gekauft wird und sie alle historischen Daten ändern möchten, die Anwendung neuer Steuersätze auf noch nicht verarbeitete Aufträge, die Behebung einiger schlechter Dateneingaben. Sie sind manchmal auch von anderen Anwendungen betroffen, die Ihre Datenschicht nicht verwenden. Sie können auch von Importen betroffen sein, die über ETL-Programme laufen, die auch Ihre Datenschicht nicht verwenden können. Wenn also die Regel in allen Fällen befolgt werden muss, muss sie in der Datenbank enthalten sein.

Wenn die Regel nur für spezielle Fälle gilt, die die Funktionsweise dieser bestimmten Eingabeseite betreffen, muss sie in der Anwendung enthalten sein. Wenn also ein Verkaufsleiter nur bestimmte Dinge hat, die er von seiner Benutzeroberfläche aus tun kann, können diese Dinge in der Anwendung spezifiziert werden.

Etwas ist es hilfreich, an beiden Orten zu tun. Zum Beispiel ist es albern, einem Benutzer zu erlauben, ein Nicht-Datum in ein Eingabefeld einzugeben, das sich auf ein Datumsfeld bezieht. Der Datentyp in der Datenbank sollte immer noch ein Datetime-Datentyp sein, aber es empfiehlt sich, einige dieser Dinge vor dem Senden zu überprüfen.