Was sind die Argumente gegen oder für das Einfügen von Anwendungslogik in die Datenbankschicht?

ANMERKUNG Die Zielgruppe von programmers.se und dba.se ist unterschiedlich und wird unterschiedliche Sichtweisen haben. In diesem Fall halte ich es für zulässig, zu duplizieren. Was sind die Argumente gegen oder für das Einfügen von Anwendungslogik in die Datenbankebene? auf programmers.se.

Ich konnte auf dba dazu bereits keine Diskussion finden, und der ursprüngliche Post sagt alles, also:

Die meisten Softwareentwickler möchten die Anwendungslogik in der Anwendungsschicht belassen, und es ist für uns wahrscheinlich eine Selbstverständlichkeit, sie hier beizubehalten. Datenbankentwickler scheinen Anwendungslogik als Trigger und gespeicherte Prozeduren in die Datenbankebene integrieren zu wollen.

Persönlich würde ich es vorziehen, so viel wie möglich in der Anwendungsebene zu belassen, um das Debuggen zu vereinfachen und die Verantwortlichkeiten der Ebenen getrennt zu halten.

Was halten Sie davon und was sollte oder sollte nicht in der Datenbankebene implementiert werden können?

NB Ich bin nicht der OP für diese Frage, habe aber den ursprünglichen Wortlaut beibehalten.

Verschiedene Gedanken ...

Ihr Datenbankcode wird Ihre Anwendungsclient-Technologie überleben. Denken Sie an ADO.NET -> Linq -> EF sowie verschiedene ORMs. Während Sie SQL Server 2000-Code aus dem letzten Jahrtausend mit allen oben genannten Clienttechnologien ausführen können .

Sie haben auch das Problem mit mehreren Clients: Ich habe .NET, Java und Excel. Das sind 3 Sätze von Anwendungslogik.

"Geschäftslogik" sollte nicht mit "Datenintegritätslogik" verwechselt werden. Wenn Kunden Transaktionen starten und verschiedene Schecks durchführen, sind das viele Datenbankaufrufe und eine lange Transaktion.

Die Anwendungslogik ist für hohe Datenmengen nicht skalierbar. Wir haben 50.000 Zeilen pro Sekunde mit gespeicherten Prozessen. Ein Schwesterteam, das Hibernate verwendet, kann nicht eine pro Sekunde erhalten

Ich möchte die gesamte Logik, die für alle Benutzer und alle Anwendungen in der Datenbank gelten muss. Das ist der einzig vernünftige Ort, um es auszudrücken.

Bei den letzten Fortune 500, bei denen ich gearbeitet habe, wurden Anwendungen in mindestens 25 Sprachen geschrieben, wobei die OLTP-Datenbank aufgerufen wurde. Einige dieser Programme gingen in den 1970er Jahren in Produktion.

Die Alternative zur Implementierung dieser Art von Anforderung in die Datenbank besteht darin, dass jeder Anwendungsprogrammierer jedes Mal, wenn er seinen Editor hochfährt, von dem Tag an, an dem er zum ersten Mal durch die Tür geht, bis zum Verlassen des Unternehmens alles oder einen Teil davon zu 100% korrekt neu implementiert Geschäft.

Was sind die Chancen?

Ist das nicht das größte " Wiederhol dich nicht " auf dem Planeten?

Ich verschiebe meine alte Antwort von "unedited" auf "programmers.se", da die Antworten zwischen den Sites ziemlich polarisiert zu sein scheinen.

Ich weiß, dass ich hier in eine Welt voller Verletzungen geraten bin, aber stelle Geschäftslogik in die Datenbank, weil:

• Sie können Hauptbenutzern in Unternehmen den direkten Zugriff auf die Datenbank ermöglichen, ohne dass sie sich Sorgen machen müssen, dass sie es vermasseln.
• Ein Hauptbenutzer kann neue Berichte erstellen, ohne auf eine neue Softwareversion warten zu müssen.
• Sie können SP / TRIGGER-Code in einer Kopie der Datenbank testen, genau wie Sie app-basierte Logik testen
• Sie können den SQL-Code behalten, um SPs und Trigger in Textdateien zu erstellen (Sie sollten dies sowieso für Tabellen- / Ansichtscode tun).
• Sie können Sprachen mischen und zuordnen, ohne die Geschäftslogik zu portieren
• Sie können Änderungen an der Geschäftslogik vornehmen, ohne jede einzelne Software zu aktualisieren
• Ihre Überwachungsstruktur ändert sich auf die gleiche Weise wie die Überwachung der Datenbankaktivität - über die Protokollierung
• Deutlich verbesserte Sicherheit und fein abgestimmte Zugriffskontrolle (die meisten app-basierten Logikimplementierungen verwenden ein eigenes Sicherheitsmodell, sodass die Daten viel einfacher kompromittiert werden können. Reversible Kennwortverschlüsselung ist keine Seltenheit)
• Die datenbankseitige Benutzersicherheit reduziert den Schaden, den SQL durch Diebstahl verursachen kann, erheblich

Die Nachteile sind: - Entwickler sind bedroht, wenn Benutzer weniger auf Entwickler für benutzerdefinierte Berichte angewiesen sind. - Entwickler müssen eine andere Programmiersprache lernen

Beides sollte für einen erfahrenen Entwickler keine Rolle spielen.

Interessanterweise sprechen die meisten Antworten von "Anwendungslogik" und nicht von "Geschäftslogik", als ob die Software keine Geschäftsfunktion bereitstellen würde.

Das wichtigste Problem ist, ob ein Layer über der Datenbank denkt, dass er Eigentümer der Daten ist. Parallelität und Datenintegrität sind Probleme, für die die Lösung ein RDBMS ist - einige Anwendungen werden so entwickelt, als ob die Datenbank nur ihr persönlicher Bit-Bucket ist, und am Ende versuchen sie natürlich, das Rad auf vielfältige Weise neu zu erfinden wird irreparabel beschädigt, sobald eine andere Anwendung auf dieselbe Datenbank zugreift

Ich habe meine Antwort darauf in meinem Blog niedergeschrieben . Mein Fazit lautet: Wenn Sie den gesamten Anwendungslebenszyklus betrachten , lässt sich dies in der Anwendung nicht skalieren.

…
3. Integritäts- / Prüfbedingungen zur zugrunde liegenden Datenbank hinzufügen,mit komplexerem Code, der in der Sprache der gespeicherten Prozeduren der Datenbank implementiert ist. Dadurch erhalten wir einen zentralen Ort für die Wartung und die absolute Durchsetzung der Regeln, auch für Anwendungen, die wir nicht kennen! Wir erhalten eine Sprache, um die Geschäftsregeln über das gesamte Anwendungsportfolio und den gesamten Lebenszyklus hinweg auszudrücken, da sich die Sprache während des Laufens weitaus häufiger ändert als die Datenbank. Und es läuft auf einem System, das bereits so geschäftskritisch ist wie die wichtigsten Anwendungen. Fehler werden durch den vorhandenen Code behandelt, der Datenbankfehler in diesen Anwendungen behandelt. Es besteht immer noch das Risiko, dass eine Anwendung nicht mehr funktioniert. Von den drei Szenarien ist dies jedoch die geringste und nur die fehlerhafte Anwendung muss geändert werden. Nicht alle von ihnen (und die meisten SP / Datenbank-Mechanismen ermöglichen die Ausnahmebedingung für eine Anwendung, wenn dies wirklich, wirklich notwendig ist). Denken Sie, dass dies auf Ihrer grünen Wiese oder in einem kleinen Unternehmen keine Rolle spielt? Wenn Ihr Geschäft erfolgreich ist, werden Sie sich in 30 Jahren wünschen, Sie hätten meine Weisheit beachtet!

… Einige [Einwände], die ich oft höre:

• Die Versionskontrolle von SP-Code, der in der Datenbank bereitgestellt wird, ist schwierig. Ich denke nicht, dass das wahrer ist als zu sagen, dass es schwierig ist, Java-Code, der auf einem App-Server bereitgestellt wird, zu versionieren. Das heißt, es ist überhaupt nicht schwierig, es ist alltäglich. Und in Ruby-land werden ganze Bücher darüber geschrieben, wie Sie Ihren Code aus einer Entwicklungsumgebung in die Produktion bringen können - etwas, mit dem keine andere Sprachgemeinschaft zu kämpfen scheint. Die Versionskontrolle einer gespeicherten Prozedur ist jedoch anscheinend zu schwierig.
• Gespeicherte Prozeduren sind schwer zu testen. Das ist seltsam. Zunächst einmal sind SPs stark typisiert. Der Compiler teilt Ihnen mit, ob ein Codepfad vorhanden ist, der keinen Sinn ergibt, und berechnet zumindest in Oracle alle Abhängigkeiten für Sie. Das ist also ein Satz üblicher Komponententests, die Sie in Ruby benötigen könnten und die sofort beseitigt wurden. Das Testen von OO-Code erfordert das Verspotten, um das Objekt in den internen Status zu versetzen, der für die Darstellung des Testszenarios erforderlich ist. Wie unterscheidet sich das Einrichten von Testdaten? Es gibt einen TAP-Hersteller für PL / SQL und andere Tools. Es gibt auch Debugger und Profiler.
• Eine Sprache für gespeicherte Prozeduren ist keine Sprache mit vollem Funktionsumfang. Nun, wir versuchen nicht, eine ganze Anwendung nur in gespeicherten Prozeduren zu schreiben! Die meisten dedizierten SP-Sprachen verfügen über alle modernen Konstrukte, die Sie erwarten, und zumindest in Oracle können Sie gespeicherte Java-Prozeduren mit allen Sprachfunktionen verwenden, die OO-Entwickler kennen, oder externe Prozeduren in jeder Sprache. Entscheidend ist, wo die Logik implementiert wird - an einem Ort, nahe an den Daten - die eigentliche Sprache ist nur ein Detail. PL / SQL wird zu systemeigenem Code kompiliert und mit der Datenbank ausgeführt. Es gibt keine leistungsstärkere Architektur als diese.
• Ich möchte keine andere Sprache lernen müssen. Mit Blick auf eine Sekunde ist dies eine große rote Fahne für jeden Entwickler (insbesondere für einen Entwickler, der Änderungen an Produktions-Apps vorschlägt, die ohnehin in anderen Sprachen verfügbar sein könnten!). In jeder modernen Umgebung gibt es eine Menge zu lernen, wie man mit Eclipse arbeitet: Ein typischer Java-Shop verfügt möglicherweise über Eclipse , WebLogic, Maven, Hudson, Anthill, Subversion und eine ganze Reihe anderer, die Sie lernen müssen, bevor Sie eine einzelne Zeile des Anwendungscodes schreiben. Die Kenntnis einer SP-Sprache auf sehr hohem Niveau ist im Vergleich dazu unkompliziert, und es wird höchstwahrscheinlich auch einen Spezialisten oder einen DBA geben, der Ihnen hilft. Ganz zu schweigen davon, dass der Entwickler-Favorit Hibernate eine eigene Abfragesprache hat…

…

Tut der SQL Dinge wie Setlogik und anwendungsorientierte Ergebnisfilterung? SQL ist eine wunderbare Set-Manipulationssprache.

Wie GBN bereits erwähnt hat, wird der SQL-Code den Anwendungscode fast durchgehend überleben.

Zwar können Sie mit EF, NHibernate, LinqToSql oder anderen Tools Code schneller generieren, doch jeder Programmierer, der seine Leistung verdient, weiß, dass nur die Optimierung von SQL den Datenabruf optimiert. Das RDBMS versteht nur SQL, Sie müssen also alles in SQL umwandeln, bevor alles gesagt und getan ist. (unter der Annahme, dass wir uns einig sind, dass TSQL und PLSQL immer noch SQL sind)

Ein Nachteil, über den die Leute nicht unbedingt diskutieren - die Profis sind hier erschöpft -, sind die Kosten.

Die CPUs auf dem Datenbankserver sind häufig die teuersten CPUs in einem Unternehmen, wenn es um die Kosten der Softwarelizenzierung geht. Die Verlagerung der Geschäftslogik in die Datenebene sollte daher mit Bedacht erfolgen und nicht unbedingt einheitlich.

Hier muss zwangsläufig das Zusammentreffen der Köpfe, dh der Köpfe von Entwicklern (DVs) und DBAs, stattfinden. Das Arbeiten mit Business Logic (BL) und das Speichern in einer Datenbank können Auswirkungen haben, die die Implementierung verherrlichen oder erschüttern können.

Für einige RDBMS-Produkte gibt es überlegene Bibliotheken / Tools / APIs für Geschäftslogik und Objektinfrastrukturen, die man schnell erlernen und in ihren Anwendungen einsetzen kann. Für andere RDBMS existieren keine Bibliotheken / Tools / APIs.

In der Vergangenheit haben Client-Server-Apps über Stored Procedures (SP) die Brücke zu BL hergestellt. Bei Produkten wie Oracle und SQL Server wurde dies frühzeitig durchgeführt. Als Open-Source-Datenbanken wie PostgreSQL und MySQL entstanden, drohten die Benutzer, mit gespeicherten Prozeduren in BL Neuland zu betreten. PostgreSQL entwickelte sich dabei sehr schnell, da nicht nur gespeicherte Prozeduren implementiert wurden, sondern auch die Fähigkeit, Kundensprachen zu erstellen, hinzukam. MySQL hat sich im Grunde genommen in der Welt der gespeicherten Prozeduren nicht mehr weiterentwickelt und wurde in einer reduzierten Form einer Sprache mit vielen Einschränkungen angeboten. Wenn es also um BL geht, sind Sie MySQL und seiner Sprache für gespeicherte Prozeduren völlig ausgeliefert.

Es bleibt wirklich nur eine Frage: Sollte BL unabhängig vom RDBMS ganz oder teilweise in der Datenbank gespeichert sein?

Denken Sie an den Entwickler. Wenn in einer Anwendung Probleme auftreten, springt der Entwickler beim Debug-Vorgang in eine Datenbank und verlässt diese, um Datenänderungen zu folgen, die möglicherweise zeitweise korrekt sind oder nicht. Es ist wie das Codieren einer C ++ - Anwendung und das Aufrufen von Assembler-Code in der Mitte. Sie müssen von Quellcode, Klassen und Strukturen zu Interrupts, Registern und Offsets UND ZURÜCK wechseln !!! Dies bringt das Debuggen auf die gleiche Ebene.

Entwickler sind möglicherweise in der Lage, eine Hochgeschwindigkeitsmethode zum Ausführen von BL in Verbindung mit Sprachkonfigurationen (Compiler-Flags für C ++, verschiedene Einstellungen für PHP / Python usw.) über Geschäftsobjekte im Speicher und nicht in einer Datenbank zu erstellen. Einige haben versucht, diese Ideologie zu überbrücken, um Code schneller in die Datenbank auszuführen, indem sie Bibliotheken schreiben, in denen das Debuggen gespeicherter Prozeduren und Trigger gut in die Datenbank integriert und scheinbar nutzbar ist.

Daher ist der Entwickler aufgefordert, Quellcode und BL in zwei Sprachen zu entwickeln, zu debuggen und zu warten.

Denken Sie jetzt an den DBA. Der DBA möchte die Datenbank so schlank und gemein wie möglich im Bereich der gespeicherten Prozeduren halten. Der DBA sieht BL möglicherweise als etwas außerhalb der Datenbank. Wenn SQL jedoch die für BL erforderlichen Daten abruft, muss das SQL schlank und gemein sein.

Nun zum Treffen der Geister !!!

Der Entwickler codiert SP und verwendet iteraktive Methoden. DBA schaut auf den SP. DBA stellt fest, dass eine einzelne SQL-Anweisung vom Entwickler geschriebene iteraktive Methoden ersetzen kann. Der Entwickler stellt fest, dass für die vom DBA vorgeschlagene SQL-Anweisung ein anderer BL-Code oder SQL-Code aufgerufen werden muss, der nicht den normalen Ausführungsplänen der SQL-Anweisung entspricht.

In Anbetracht dessen wird die Konfiguration, Leistungsoptimierung und SP-Codierung eine Funktion der Tiefe und Datenintensität von BL für den Datenabruf. Je tiefer und datenintensiver der BL ist, desto mehr Entwickler und DBA müssen in Bezug auf die Datenmenge und die Verarbeitungsleistung der Datenbank auf derselben Seite sein.

FAZIT

Die Art des Datenabrufs sollte immer sowohl Entwickler- als auch DBA-Camps umfassen. Es müssen immer Zugeständnisse gemacht werden, welche Codierungsmethoden und Datenabrufparadigmen für Geschwindigkeit und Effizienz zusammenarbeiten können. Wenn die Aufbereitung der Daten für den Quellcode nur ein Mal erfolgt, bevor der Code die Daten erhält, sollte der DBA die Verwendung von Lean- und Mean-SQL vorschreiben. Wenn der BL etwas ist, mit dem der DBA nicht in Einklang ist, dann sind die Zügel in den Händen des Entwicklers. Aus diesem Grund sollte sich der DBA als Teil des Projektteams und nicht als Insel für sich selbst sehen, während der Entwickler den DBA die Feinabstimmung des SQL überlassen muss, wenn dies dies rechtfertigt.

Es ist eine schöne Frage, die Sie auf einer Website voller Datenbankadministratoren stellen können. Hoffentlich sind die meisten Antworten "pro", um die Datenbank in einem ACID-Status zu halten und damit die Geschäftslogik in der Datenbank zu halten. :-)

Meiner Meinung nach sollten Sie die Geschäftslogik sowohl in Ihrer (n) Anwendung (en) als auch in Ihrer (n) Datenbank (en) implementieren. Dieser Ansatz wird mehr Zeit und Geld kosten, aber ich denke, er wird als Ergebnis eine qualitativ bessere Geschäftslösung haben.

Wie Adam Musch oben sagte, gibt es hier mehr für die Leistung zu berücksichtigen. CPU auslastung. Speichernutzung.

Verhindern Sie, dass offensichtlich falsche Dinge in die Datenbank gelangen.

• Entfernen Sie E-Mail-Adressen, die nicht den grundlegenden Anforderungen entsprechen.
• Längen prüfen

Wenn Sie tiefer gehen, müssen Entscheidungen getroffen werden. Der DB-Server ist ein sehr teurer Ort, um Dinge zu erledigen, die der Client leicht tun könnte. Beispiel: Datenformatierung, Datumsformatierung, Zusammenstellen von Zeichenfolgen usw. clientseitig.

Rechnen Sie auf dem Client oder auf dem DB-Server? Für mich hängt das von der Komplexität und Anzahl der Datensätze ab. Geschäftslogik sollte eigentlich in der DB selbst gemacht werden, damit alles gleich behandelt wird.
Sie sollten wirklich eine API mit Ansichten zum Lesen und Speichern von Prozessen erstellen, um die Daten in die Datenbank zu schreiben und sich in Zukunft Kopfschmerzen zu ersparen.

Nutzen Sie die Stärken jedes Ziels zu Ihrem Vorteil.