it-swarm-eu.dev

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

[~ # ~] note [~ # ~] Das Publikum von programmers.se und dba.se ist unterschiedlich und hat unterschiedliche Standpunkte Diese Instanz ist meiner Meinung nach gültig, um Was sind die Argumente gegen oder für das Einfügen von Anwendungslogik in die Datenbankebene? auf programmers.se zu duplizieren.

Ich konnte bereits keine Diskussion über dba finden, und der ursprüngliche Beitrag sagt alles, also:

Die meisten Softwareentwickler möchten die Anwendungslogik in der Anwendungsschicht behalten, und es ist für uns wahrscheinlich selbstverständlich, sie hier zu belassen. Datenbankentwickler scheinen die Anwendungslogik als Trigger und gespeicherte Prozeduren in die Datenbankebene einfügen zu wollen.

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

Was denken Sie darüber und was sollte oder sollte nicht in der Datenbankschicht implementiert werden können?

N.B. Ich bin nicht der OP für diese Frage, habe aber den ursprünglichen Wortlaut intakt gelassen.

74
Phil Lello

Verschiedene Gedanken ...

Ihr Datenbankcode überlebt Ihre Anwendungsclient-Technologie. Denken Sie an ADO.NET -> Linq -> EF sowie an verschiedene ORMs. Während Sie immer noch SQL Server 2000-Code vom letzten Jahrtausend für alle oben genannten Client-Technologien 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 Clients Transaktionen starten und verschiedene Überprüfungen durchführen, sind das viele Datenbankaufrufe und eine lange Transaktion.

Die Anwendungslogik lässt sich nicht für hohe Datenmengen skalieren. Wir haben 50.000 Zeilen pro Sekunde mit gespeicherten Prozessen. Ein Schwesterteam, das Hibernate verwendet, kann nicht eins pro Sekunde erhalten

56
gbn

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, die in die Datenbank OLTP) kamen. Einige dieser Programme wurden in den 1970er Jahren in Produktion genommen.

Die Alternative zur Implementierung dieser Art von Anforderung in der Datenbank besteht darin, dass jeder Anwendungsprogrammierer sie jedes Mal, wenn er seinen Editor startet, von dem Tag an, an dem er zum ersten Mal durch die Tür geht, bis zum Verlassen des Unternehmens, 100% richtig oder teilweise neu implementiert Geschäft.

Was sind die Chancen?

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

Ich verschiebe meine alte Antwort unbearbeitet von programmers.se, da die Antworten zwischen den Websites ziemlich polarisiert zu sein scheinen.

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

  • Sie können Geschäftsbenutzern direkten Zugriff auf die Datenbank gewähren, ohne sich Sorgen machen zu müssen, dass sie es vermasseln (oder sich weniger Sorgen machen als mit app-basierter Logik).
  • 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 die SQL beibehalten, um SPs und Trigger in Textdateien zu erstellen (Sie sollten dies trotzdem für Tabellen-/Ansichtscode tun).
  • Sie können Sprachen mischen und anpassen, ohne die Geschäftslogik zu portieren
  • Sie können Änderungen an der Geschäftslogik vornehmen, ohne jede Software zu aktualisieren
  • Ihre Überwachungsstruktur ändert sich genauso wie Ihre Datenbankaktivität - über die Protokollierung
  • Deutlich verbesserte Sicherheit und feinkörnige 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-Betrüger anrichten können, 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 nicht für die Bereitstellung einer Geschäftsfunktion vorhanden wäre.

29
Phil Lello

Das wichtigste Problem ist, ob eine 'Schicht' über der Datenbank denkt, dass sie die Daten besitzt. 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 natürlich versuchen sie am Ende, das Rad auf alle möglichen Arten neu zu erfinden irreparabel beschädigt werden, sobald eine andere Anwendung auf dieselbe Datenbank zugreift

Ich habe meine Antwort darauf geschrieben in meinem Blog . Mein Fazit lautet: Wenn Sie dies in der Anwendung tun, wird es einfach nicht skaliert, wenn Sie den gesamten Anwendungslebenszyklus berücksichtigen.


3. Fügen Sie der zugrunde liegenden Datenbank Integritäts-/Überprüfungsbeschränkungen hinzu , wobei komplexerer Code in der Sprache der gespeicherten Prozedur der Datenbank implementiert ist. Dadurch erhalten wir einen zentralen Standort für die Wartung und können die Regeln auch für Anwendungen, von denen wir nichts wissen, absolut durchsetzen! Wir erhalten eine Sprache, in der die Geschäftsregeln über das gesamte Anwendungsportfolio und den gesamten Lebenszyklus hinweg ausgedrückt werden, da sich die Sprache du jour 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 natürlich kaputt geht, aber von den drei Szenarien ist dies das geringste, und nur die kaputte Anwendung muss geändert werden, nicht alle (und die meisten SP-/Datenbankmechanismen lassen eine Ausnahme zu gemacht für eine Anwendung, wenn das wirklich, wirklich notwendig ist). Denken Sie, dass dies auf Ihrer grünen Wiese oder in Ihrem 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] höre ich oft:

  • Es ist schwierig, die Version zu kontrollieren SP Code, der in der Datenbank bereitgestellt wird. Ich denke, das ist nicht wahrer, als es zu sagen schwierig zu versionieren Java Code, der auf einem App-Server bereitgestellt wird, das heißt, es ist überhaupt nicht schwierig, es ist alltäglich. Und in Ruby-Land werden fast ganze Bücher geschrieben Wie Sie Ihren Code aus einer Entwicklungsumgebung in die Produktion bringen, 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. Dies ist eine seltsame. Zunächst einmal sind SPs stark typisiert. Der Compiler teilt Ihnen mit, ob ein Codepfad ein- oder ausgeht, der keinen Sinn ergibt, und berechnet zumindest in Oracle alle Abhängigkeiten für Sie. Das ist also eine Reihe allgemeiner Komponententests, die Sie möglicherweise in Ruby sofort eliminiert) benötigen. Um OO Code zu testen, muss verspottet werden, um das Objekt in den internen Zustand zu versetzen erforderlich, um das Testszenario darzustellen - wie unterscheidet sich das Einrichten von Testdaten? Es gibt einen TAP-Produzenten für PL/SQL und andere Tools. Es gibt auch Debugger und Profiler.
  • Eine Sprache für gespeicherte Prozeduren ist keine voll funktionsfähige Sprache. Nun, wir versuchen nicht, eine gesamte Anwendung nur in gespeicherten Prozeduren zu schreiben! Die meisten dedizierten SP Sprachen haben alle modernen Konstrukte, die Sie erwarten würden, und zumindest in Oracle können Sie Java Gespeicherte Prozeduren mit allen Sprachfunktionen = verwenden OO Entwickler sind mit oder externen Prozeduren in jeder Sprache vertraut. Entscheidend ist, wo die Logik implementiert wird - an einem Ort, in der Nähe der Daten - die eigentliche Sprache ist nur ein Detail. PL/SQL Kompiliert zu nativem Code und wird in Bearbeitung mit der Datenbank ausgeführt. Es gibt keine leistungsstärkere Architektur als diese.
  • Ich möchte keine andere Sprache lernen müssen. Für eine Sekunde zu übersehen, ist eine große rote Fahne in jedem Entwickler (insbesondere in einem, der vorschlägt, die Produktion zu ändern Apps, die ohnehin auch in anderen Sprachen verfügbar sein könnten!) In jeder modernen Umgebung gibt es viel zu lernen: Ein typischer Java Shop kann Eclipse, WebLogic, Maven, Hudson, Anthill, Subversion, und eine ganze Reihe anderer, die Sie lernen müssen, bevor Sie eine einzelne Zeile Anwendungscode schreiben. Kenntnisse auf sehr hohem Niveau SP Sprache ist im Vergleich einfach, und es wird mehr als Wahrscheinlich ist er auch ein Spezialist oder ein DBA, der Ihnen hilft. Ganz zu schweigen davon, dass der Entwickler-Favorit Hibernate über eine eigene Abfragesprache verfügt.

17
Gaius

Macht das SQL Dinge wie Set-Logik und anwendungsorientierte Ergebnisfilterung? SQL ist eine wunderbare Set-Manipulationssprache.

Darüber hinaus wird der SQL-Code, wie GBN oben erwähnt hat, den Anwendungscode fast überall überleben.

Zwar können Sie mit EF oder NHibernate oder LinqToSql oder was auch immer Code schneller generieren, aber jeder Programmierer, der seine Leistung verdient, weiß, dass nur die Optimierung des SQL den Datenabruf optimiert. Das RDBMS versteht nur SQL, daher müssen Sie alles in SQL umwandeln, bevor alles gesagt und getan ist. (vorausgesetzt, wir können uns darauf einigen, dass TSQL und PLSQL immer noch SQL sind)

12
jcolebrand

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 für die Softwarelizenzierung geht. Die Verlagerung der Geschäftslogik auf die Datenebene sollte daher mit Bedacht und nicht unbedingt einheitlich erfolgen.

11
Adam Musch

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

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

In der Vergangenheit haben Client-Server-Apps über Stored Procedures (SP) die Brücke zu BL geschlagen. Bei Produkten wie Oracle und SQL Server wurde dies frühzeitig durchgeführt. Als Open-Source-Datenbanken wie PostgreSQL und MySQL entstanden, bestand für diejenigen, die sie verwendeten, die Gefahr, mit gespeicherten Prozeduren in BL neue Wege zu beschreiten. PostgreSQL reifte dabei sehr schnell, da nicht nur gespeicherte Prozeduren implementiert wurden, sondern auch die Möglichkeit, Kundensprachen zu erstellen. MySQL hat sich in der Welt der gespeicherten Prozeduren im Grunde genommen nicht mehr weiterentwickelt und ist in einer abgespeckten Form einer Sprache mit vielen Einschränkungen erhältlich. Wenn es um BL geht, sind Sie MySQL und seiner Sprache für gespeicherte Prozeduren völlig ausgeliefert.

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

Denken Sie an den Entwickler. Wenn in einer Anwendung Probleme auftreten, springt der Entwickler beim Debug-Prozess in eine Datenbank ein und aus, um Datenänderungen zu verfolgen, die zeitweise möglicherweise 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 wechseln UND ZURÜCK !!! Dies bringt das Debuggen auf das gleiche Niveau.

Entwickler können möglicherweise eine Hochgeschwindigkeitsmethode zum Ausführen von BL in Verbindung mit Sprachkonfigurationen (Compiler-Flags für C++, unterschiedliche Einstellungen für PHP/Python usw.) über Geschäftsobjekte erstellen, die sich im Speicher und nicht in einer Datenbank befinden. Einige haben versucht, diese Ideologie für eine schnellere Ausführung von Code in der Datenbank zu überbrücken, indem sie Bibliotheken geschrieben haben, in denen das Debuggen von gespeicherten Prozeduren und Triggern 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 schlank halten und im Bereich der gespeicherten Prozeduren so viel wie möglich bedeuten. Der DBA sieht BL möglicherweise als etwas außerhalb der Datenbank. Wenn SQL jedoch die für BL benötigten Daten anfordert, muss SQL schlank und gemein sein.

Nun zum Treffen der Geister !!!

Entwicklercodes SP und verwendet iteraktive Methoden. Der DBA überprüft den SP. Der DBA stellt fest, dass eine einzelne SQL-Anweisung die vom Entwickler geschriebenen iteraktiven Methoden ersetzen kann. Der Entwickler sieht, dass die vom DBA vorgeschlagene SQL-Anweisung erforderlich ist Aufrufen von anderem BL-bezogenem Code oder SQL, das nicht den normalen Ausführungsplänen der SQL-Anweisung folgt.

In Anbetracht dessen wird die Konfiguration, Leistungsoptimierung und SP-Codierung) eine Funktion der Tiefe und Datenintensität von BL für den Datenabruf. Je mehr Tiefe und Datenintensität der BL hat, desto Weitere Entwickler und DBA müssen sich auf derselben Seite befinden, um die Datenmenge und die Verarbeitungsleistung für die Datenbank zu ermitteln.

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 Vorbereitung der Daten für die Verarbeitung des Quellcodes nur einmal 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 übereinstimmt, liegen 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 durchführen lassen muss, wenn dies gerechtfertigt ist.

7
RolandoMySQLDBA

Es ist eine nette Frage, die man auf einer Website voller Datenbankadministratoren stellen kann. Hoffentlich sind die meisten Antworten "pro", um die Datenbank in einem ACID-Zustand zu halten und damit die Geschäftslogik in der Datenbank zu halten. : -)

Meiner Meinung nach sollten Sie die Geschäftslogik sowohl in Ihren Anwendungen als auch in Ihren Datenbanken implementieren. Dieser Ansatz wird mehr Zeit und Geld kosten, aber ich denke, dass dies zu einer qualitativ besseren Geschäftslösung führen wird.

4

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

Blockieren Sie offensichtlich falsche Dinge, um in die Datenbank zu gelangen.

  • Entfernen Sie E-Mail-Adressen, die in keiner grundlegenden Weise übereinstimmen.
  • Längen prüfen

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

Führen Sie die Mathematik/Verarbeitung auf dem Client oder auf dem DB-Server durch? Für mich hängt das von der Komplexität und der Anzahl der beteiligten Datensätze ab. Geschäftslogik sollte wirklich in der Datenbank selbst ausgeführt 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 Endes zu Ihrem Vorteil.

2
Matt M