Argumente für/gegen die Geschäftslogik in gespeicherten Prozeduren

https://stackoverflow.com/questions/484516

20-08-2019
|

Frage

Was sind die Argumente für und wider von Geschäftslogik in gespeicherten Prozeduren?

Lösung

Vor Stored Procedures: Business-Logik in der Programmierung Raum

Ich lege großen Wert auf die Kraft des Ausdrucks, und ich weiß nicht die SQL-Raum finden alles, was expressive zu sein. Benutzen Sie die besten Tools, die Sie für die am besten geeigneten Aufgaben zur Hand haben. Hantieren mit Logik und höherer Ordnung Konzepten wird am besten auf höchstem Niveau durchgeführt. Folglich Speicherung und Manipulation von Massendaten am besten auf der Serverebene durchgeführt wird, wahrscheinlich in Stored Procedures.

Aber es hängt davon ab. Wenn Sie mehrere Anwendungen mit einem Speichermechanismus interagieren und Sie wollen sicherstellen, dass es behält seine Integrität und Workflow, dann sollten Sie die gesamte Logik in die Datenbank-Server auslagern. Oder werden vorbereitet gleichzeitige Entwicklung in mehreren Anwendungen zu verwalten.

Andere Tipps

Ich bin durchaus dagegen. Einer der wichtigsten Gründe ist der erste Grund earino angegeben - sie lebt in einem Ort. Sie können es nicht sehr leicht in der Quellcodeverwaltung integrieren. Es ist fast unmöglich, zwei Devs haben auf einer gespeicherten proc zugleich arbeiten.

Mein anderer Hauptkritikpunkt ist, dass SQL bei Darstellung komplexe Logik einfach nicht sehr gut ist. Sie haben kein Konzept des Umfangs, Code neigt Kopie kleisterte zu sein, weil es eine weniger Fähigkeit, die Wiederverwendung von Code ist (im Gegensatz zu einer OO-Sprache entgegengesetzt).

Sie haben die Entwickler geben Zugriff auf die Datenbank dort zu entwickeln. In vielen Organisationen Ich habe an den Daten Menschen sind in einer anderen Welt als die Devs mit unterschiedlichen Berechtigungen gearbeitet, usw. Halten Sie die Devs aus der Datenbank in diesen Fällen wäre schwieriger.

Ich bin von der Schule des Denkens, die besagt, dass, solange die Geschäftslogik:

lebt in ein Ort
, wo es richtig dokumentiert
richtiger Zugriff wird durch Dienstleistungen zur Verfügung gestellt, die lose gekoppelt werden können
durch eine veröffentlichte abstrahierte Schnittstelle

ist ich egal, wenn die Logik in einer gespeicherten Prozedur lebt, in einem J2EE-Middle-Tiere, in einem Clip Expertensystem, oder wo auch immer. Egal wo Sie sich unsere Geschäftslogik speichern das „Gesetz der Erhaltung des Elends“ wird gewährleistet, dass jemand sagen, dass es die falsche Idee war, weil Komponente / Repository X für Technik / Methode Y ausgelagert werden muss.

Einige Gedanken: Bitte beachten Sie, das ist eine Java-centric Antwort, aber die der Großteil meiner letzten (letzten 10 Jahre) Erfahrung

(1) Die gleichzeitige Entwicklung von einem (großen) Team von Entwicklern. Wenn Sie Anwendung ausreichend komplex ist, dass jeder Entwickler nicht ihre eigene private Version des DB einrichten kann (mit besuchen Links / ref Daten / etc ...), ist es sehr schwierig, ein ganzes Team von Entwicklern haben alle arbeiten an der gleiche Satz von PL-SQL (zum Beispiel) Pakete zu derselben in einem gemeinsamen DEVL DB gespeicherten Zeit? Dann steckte (meine Erfahrung) mit Arbeiten in einem DB mit ungültigen Verfahren / Nichtübereinstimmung von Code-Tabellen als Personen Änderungen vornehmen ...

Als Java Architekt, ich glaube, sein viel einfacher, jeden Entwickler hat verfügt über eine eigene JBoss-Instanz auf ihrem Desktop und arbeitet leicht auf ihren eigenen Satz von Funktionalität und in ihrem eigenen Tempo zu integrieren, ohne alle Auswirkungen auf andere ... was bringt ich ...

(2) Continuous Integration Toolset Zwar gibt es in der DB Welt einige ähnlichen ‚Konzepte‘ existiert, ist meine Erfahrung mir gezeigt, dass die Kombination aus (i meine aktuellen Best-of-Breed-Favoriten hier bin Kommissionierung):

MVN - Build-System
junit - automatisierte Unit-Tests
nexus - Repo-Manager (verwaltet des Artefakts Lifecycles Version, Schnappschüsse und Releases)
hudson - ci Build-Server
Sonar - statische Analyse-Tool / Code-Coverage-Berichte / VIEL mehr

ein großes Projekt laufen alle oben genannten (kostenlose Tools) unter Verwendung ermöglicht eine konsistente / einfache Möglichkeit, XP, um die Massen zu liefern und Qualitätskontrollen über einen gesamten IT-Mitarbeiter durchzusetzen. Oracle / PL-SQL nicht die Toolsets müssen übereinstimmen

(3) Werkzeuge / Bibliotheken / etc ... Java hat Zugriff auf eine erstaunliche Reihe von Dienstleistungen, die anderen Plattformen nicht berühren können - einige kostenlos, einige nicht. sogar grundlegend diejenigen, wie log4j (ja, sie haben es für PL / SQL, aber pulease ... sein nicht annähernd das gleiche) ermöglichen Dinge wie ermöglicht es Entwickler, flexibel einstellbare Protokollierung zu erstellen, die im laufenden Betrieb (ideal für dubugging) geändert werden können . Automatisierte API Dokumentation (via Javadoc-). Automatisierte Einheit Testabdeckung Berichte. Unglaubliche IDEs (Eclipse) mit integriertem Debugger / autodeploy zu App-Servern. Eine API mit jeder Art von Service unter der Sonne zu verbinden, Open-Source-Bibliotheken, etwas zu tun, und 100% Unterstützung von jedem Anbieter

(4) Wiederverwendung von Services. was jemand kommentiert ist wahr. Wenn Sie schwere haben datengetriebene Geschäftsregeln , dann können Sie argumentieren, dass diese in der DB-Schicht leben sollten. Warum? zu verhindern, dass die mittlere Ebene mit (n), die Logik duplizieren alle mit.

Aber das gleiche gilt für Geschäftsregeln gesagt werden, die keine Daten getrieben oder so komplex, dass OO eine natürliche Wahl ist . Wenn Sie all Business-Logik in der DB bleiben, dann sind sie nur über die DB zur Verfügung.

Was passiert, wenn Sie möchten, Validierung im Client oder in der Mitte App Tiere getan haben und eine Rundfahrt mit der DB speichern?
Was passiert, wenn Sie nur Daten in der mittleren Ebene lesen gecached werden sollen (für die Leistung) und haben Geschäftsregeln auszuführen gegen die im Cache gespeicherten Daten?
Was passiert, wenn Sie eine mittlere Ebene eine Dienstleistung, die DB-Zugriff nicht erforderlich ist, oder Sie haben einen Kunden, die ihre eigenen Daten liefern können?
Was passiert, wenn die datenabhängigen Teil der Geschäftsregeln dann externe Dienste zugreifen muss? Dann beenden Sie mit mit fragmentierten Geschäftslogik, die wie folgt aussieht:

retCode = validateSomeDate(date);
if (retCode == 1) then
   evaluateIfCustomerGetsEmail(...)//probably more stored proc invocations here...
   sendEmailMsg(....)
else if (retCode == 2) then
   performOtherBizLogicStuf(...) //again, may need data, may not need data
   triggerExternalsystemToDoSomething(...) //may not be accessible via PL/SQL 
fi

Ich bin sicher, wir haben alle gesehen, Systeme wie die oben geschrieben und hatten sie bei 02.00 debuggen. Sein extrem schwierig, einen kohärenten Sinn eines komplexen Prozesses zu erhalten, wenn die Geschäftslogik zwischen den Ebenen fragmentiert ist, und in einigen Fällen wird es unmöglich sein, zu halten.

„Sie können es in Quelle sehr leicht nicht integrieren Kontrolle.“ - wenn Sie den Code setzen, der die gespeicherte Prozedur in ein Skript erstellt, die kontrolliert Version ist, geht dieser Einwand weg. Wenn Sie Scott Ambler agile Datenbank Ideen folgen, das ist genau das, was Sie tun sollen.

Nicht alle Entwickler sind gute Daten-Modellierer. Ich kann mir schreckliche Schemata von Entwicklern erstellt, die dachten, dass ein Dilettantismus Kenntnisse in SQL-Datenbank sie Experten. Ich denke, es gibt eine Menge Wert ist Entwickler, die mit DBAs und Datenmodellierer arbeiten.

Wenn nur eine Anwendung auf die Datenbank verwendet, würde ich sagen, dass Business-Logik in der mittleren Ebene erscheinen. Wenn viele Anwendungen die Datenbank teilen, vielleicht ist es besser, sie in der Datenbank zu setzen.

SOA bietet einen Mittelweg: Dienstleistungen, um ihre Daten besitzen. Nur die Service-Zugriff auf die Daten; um Daten zu erhalten bedeutet, durch den Dienst gehen. In diesem Fall ist es möglich, die Regeln in jeder Stelle zu setzen.

Anwendungen kommen und gehen, aber die Daten bleiben.

Ein weiterer Grund, nicht in sprocs Business-Logik zu speichern - begrenzte Skalierung Fähigkeiten der DB. Es ist sehr häufig auftretende Situation, wo Ihre Datenbank Ihren Engpass ist, deshalb ist es eine gute Idee ist, so viel Last des DB wie möglich zu machen.

Meine wenige Beobachtungen:

Zugunsten von Stored Procedures:

nach einiger Zeit des Lebens Projekt, in den meisten Fällen der Engpass ist die Datenbank nicht die Webserver - und gespeicherte Prozeduren sind viel, viel schneller
Verwenden von SQL Profiler mit ORM SQL-Abfragen generiert ist sehr schwierig; dies ist einfach, mit Stored Procedures
Sie ein Update für gespeicherte Prozedur bereitstellen können sofort, ohne Service-Fenster
für die Leistung, es ist einfacher, eine gespeicherte Prozedur als ORM-Code zu optimieren
Sie viele Anwendungen mit dem gleichen db / gespeicherte Procs
beliebig komplexe Datenszenario ist eine Stimme für gespeicherte Prozeduren

Zugunsten application / ORM:

Sie können Code-Repository verwenden (mit gespeicherten Procs ist es immer noch möglich, aber teuer)
java / c # Sprache ist ein besseres Werkzeug Business-Logik
java / c # ist einfacher zu debuggen (mit Ausnahme des dynamisch generierten ORM SQL)
Unabhängigkeit von Datenbank-Engine (dies ist jedoch nicht sehr wahrscheinlich, dass ein Projekt Änderung Datenbank in einem anderen)
ORM stellt Datenmodell, das einfach zu bedienen ist

Meiner Meinung: für große Projekte - geht für gespeicherte Prozeduren, für die andere - Anmeldung / ORM wird gut funktionieren.

Am Ende eines Tages, der das einzige, was zählt, ist die Datenbank.

Die Geschäftslogik sollte an einem Ort eingekapselt werden. Wir können garantieren, dass die Logik immer konsequent ausgeführt wird und ausführen. Mit Klassen, die alle Aktivitäten ein Unternehmen auf der Datenbank beinhalten, müssen durch laufen wir können garantieren, dass alle Validierung ordnungsgemäß ausgeführt wird. Es gibt einen Platz für diesen Code und jeder Entwickler an dem Projekt einfach diese Klasse öffnen und die Logik zu sehen (weil Dokumentation kann und wird nicht mehr aktuell erhalten, der Code ist die einzige zuverlässige Form der Dokumentation ist).

Dies ist schwierig mit gespeicherten Prozeduren zu tun. Sie können mehr als ein sproc mit der gleichen Tabelle zu tun haben (s). mehrere sprocs Chaining zusammen, so dass die Logik in nur einer residiert bekommt unhandlich. Das ist Streik ein. Wie bestimmen Sie „Was sind alle Geschäftsregeln Einheit X Umgebung“ in der Datenbank? Viel Spaß beim suchen Tausende von sprocs versuchen, dass auf die Spur.

Nummer zwei ist, dass Sie Ihre Geschäftslogik zu Ihrem Persistenzmechanismus sind zu binden. Sie können nicht alle Ihre Daten in derselben Datenbank speichern oder einige in XML befinden können usw. Diese Art von Inkonsistenz ist auf dem Entwickler schwierig.

Die Validierung ist schwierig durchzuführen, wenn die Logik nur in der Datenbank befindet. Nennen Sie wirklich einen sproc jedes Feld auf dem Dateneingabeformular zu validieren? Validierungsregeln und Geschäftslogik sind eng miteinander verwandt. Diese Logik sollte alle an der gleichen Stelle durchgeführt werden!

+:SQL server manchmal optimiert den code

+:Sie sind gezwungen, um Parameter, die Grenzen SQL-injection-Probleme

-:Ihr code hängt von einer einzigen Datenbank (in einigen Datenbanken müssen nicht einmal SP)

-:Code ändern, müssen Sie die Verbindung zu einer Datenbank

-:Logik ist nicht gut organisiert

Ich persönlich bin dagegen, aber ich musste es einmal auf einen wirklich anstrengenden website.Mit SP in MS SQL brachte enorme Vorteile, aber sobald ich implementierten caching-diese Leistungen waren nicht so groß, nicht mehr.

Es gibt ein Sprichwort ...

Wenn alles, was Sie nur einen Hammer hat, sieht alles aus wie ein Nagel.

In meiner bescheidenen Meinung nach gibt es keine eine Antwort, die alle Umstände passen. Es scheint mir, dass viele Leute einfach davon ausgehen, dass in der Datenbank Business Logic setzt immer falsch ist.

Eine Menge Arbeit wurde getan, um die Transaktionsverarbeitung, insbesondere Bulk-Operationen, sehr effizient, wenn Sie fertig auf der Datenbankseite zu machen. Auch die Code-Management in Datenbanken hat erheblich verbessert, da die meisten der Stellungnahmen gegen Datenbanken gebildet wurden.

Ich denke, es ist falsch, den Datenbankserver als nur eine Persistenz-Schicht zu betrachten. Wenn Ihre Verarbeitungsaktivitäten am effizientesten sind, wenn sie auf dem DB-Server erfolgt dann tun sie es.

Wenn nicht, dann tun sie anderswo.

Es kommt alles auf, was am besten passt die Anwendung, die Sie im Moment arbeiten, das Team, mit dem Sie arbeiten, und der Kunde, der Sie eingestellt.

Das nur meine 2 Cent.

Sie können Unit-Test-Business-Logik, wenn sein in einer Business-Logik-Schicht. Wenn es trennt vollständig die persistance Operationen verspottet werden können, so dass Sie die BL nur testen. Eine gespeicherte Prozedur ist weit schwieriger zu warten / debug / Unit-Test als z.B. Linq und c #.

DBMS! = Anwendungsserver

Funktionale Programmierung (DB Stored Procedure) vs OOP. Für große Programme ist OOP nur Standard.
IDE - Eclipse, IntelliJ, Netbeans mit allen Plugins für das Debuggen, Testen und Analyse funktioniert nur mit realen Programmiersprachen. Statische Code-Tools .
Versionskontrolle, wenn Sie einen für PLSQL & co bekommen. ist toll. Wenn Sie direkt von Ihnen erhalten „Ansicht synchronisieren“ IDE -. Sie der Glückliche real
Ihr System skalieren. Für DB-System ist die Hölle. Sie müssen teure Hardware für andere „Knoten“. Replikation. Und wahrscheinlich für jeden Knoten lizenzieren. Vergessen Sie nicht, Sie immer noch in „funktionaler Programmierung“ sind und Mühe zu verstehen und zu pflegen solche Systeme ist viel größer.
Sie sind mit Ihrer DB stecken, versuchen, einen neuen von einem anderen Unternehmen
Und so weiter ...

Gespeicherte Prozedur für Business-Logik ist eine schlechte Praxis heute. Verwenden Sie 3-Tier-Architektur statt.

Performance massiv, indem Logik in die gespeicherte Prozeduren verbessert werden, vor allem, wenn explizite Transaktionen beteiligt sind.

Nach meiner Erfahrung, Anwendungsentwickler sind nicht sehr gut optimierte Datenbank-Code zu schreiben, und nicht dazu neigen, über die Parallelität oder Performance-Probleme zu denken.
Wenn die Geschäftslogik in der Anwendungsschicht gehalten wird, neigen Sie dazu, große Mengen von Daten zu verschieben, zu haben (oft in vielen Umläufen) über das Netzwerk, duplizieren es im Speicher auf dem DB-Server und mindestens einmal in dem App-Server, und tut eine Last von Zeile-für-Zeile-Verarbeitung in der App, während Sie offen halten eine Transaktion. Dann beschweren sich die App-Entwickler, dass die Datenbank langsam und hält Deadlocks.

Wenn Sie die Logik in der DB setzen, wo immer es möglich ist, neigen Sie dazu, nur einige Parameter über das Netzwerk übergeben, werden keine Transaktionen statt, während Sie auf Netzwerk-Ressourcen warten, und das Ganze geht wie ein geölter Blitz. Datenbanken sollten natürlich gehen in der Quellcodeverwaltung wie jede andere Quellcode .. es gibt viele Tools für das sind.

@ Nick: „Ich bin durchaus dagegen Einer der größten Gründe, warum der erste Grund ist earino angegeben -. Es an einem Ort lebt, Sie können es in Quelle nicht integrieren Steuerung sehr einfach Es ist fast unmöglich, zwei Devs zu haben. arbeiten an einer gespeicherten Prozedur zur gleichen Zeit. "

Nicht, dass ich das Argument für die auf gespeicherten Prozeduren Business-Logik setzen (alle im Gegenteil). Aber diese Gründe, die Sie nach vorne keinen Sinn machen, setzen. Eine gespeicherte Prozedur ist einfach eine SQL / DDL Artefakt, das auf Quellcodeverwaltung gespeichert werden können, und das ist auch ein Einsatz Artefakt (das heißt, etwas an die dba für den Einsatz übergeben, viel die gleiche Art und Weise Sie Ihren Krieg / Ohr übergeben würde Artefakte auf die IT / deployment Liasons) Ein oder mehrere Entwickler auf der gleichen gespeicherte Prozedur aus der Quellcodeverwaltung nur in der gleichen Art und Weise arbeiten, können Sie mit einfachen alten Quellcode tun werde -. durch Verzweigung, Versionierung und das Verschmelzen

Nun, wenn die einzige Kopie der gespeicherten Prozedur (und die Pakete, die sie enthalten) nur in der Datenbank vorhanden sind, dann natürlich können Sie nicht steuern, mit der Quellcodeverwaltung (und alle zu, dass Probleme im Zusammenhang). Allerdings, das ist nicht ein Problem der gespeicherten Prozedur aber ein Problem der Unfähigkeit in Bezug wie diesen Code zu verwenden. Es ist, als ebenso eine Anzeige von Ungeschicklichkeit als nur eine Kopie des Quellcodes lebt auf Herstellung.

ich in Systemen mit großen Mengen von Code gearbeitet haben, Java und PLSQL / DDLs und sie wurden alle auf Clearcase versioniert. Sie wurden alle als Quellcode behandelt, die mit einem strengen Prozess zusammengestellt und eingesetzt werden würde, mit verschiedenen Teams an ihnen zu arbeiten. Noch nie hatte ein Problem wie das, was Sie beschreiben.

Es gibt kontextspezifische Gründe nicht Geschäftslogik in gespeicherten Prozeduren zu setzen, aber diese sind nicht gültig diejenigen.

High Budget-Projekte: Wenn Sie Ihre auf den neuesten Stand Daten im Speicher zu halten und die Änderungen auf dem Datenträger gespeichert regelmäßig, würden Sie wollen, Business-Logik außer dem DB-Server zu handhaben. Anwendungsfall:. dienen Daten aus dem RAM, komplexen Caching-Mechanismen

Low-Budget-Projekte: Wenn Sie das auf dem neuesten Stand Daten auf der Festplatte halten und Ihre Präsentation ist abhängig von Festplatte liest, in gespeicherten Prozeduren Geschäftslogik Handhabung können Sie die Entwicklungszeit sparen. Anwendungsfall: dient Daten von der Festplatte

Es gibt verschiedene Arten von „Business-Logik“. Betrachten Sie es als Partitionierung auf, wie es mit anderen Schichten oder Dienstleistungen in engen Zusammenhang steht. Hier sind einige Faustregeln aus einer MVC-Perspektive:

a) In der Datenbank (Stored Procedure), wenn es meist datenbezogene ist, und kann getan werden, mit Verknüpfungen und relativ einfach WHERE und SELECT-Klauseln.

b) In der Steuerung, wenn es meistens Routing oder Versand verwandten; das heißt, in größerem Maßstab UI Flusssteuerung in Bezug auf dem Bildschirm oder Ressourcenauswahl.

c) Im Modell oder View-Modell, wenn es komplexe oder komplizierte Berechnungen und / oder conditionals beinhaltet.

d) In der Ansicht (wie Razor), wenn es in erster Linie ein Problem mit der Anzeige, wie „freundlich“ Neuformatierung und relativ einfach zu implementieren. (Wenn es komplex ist, sollten Sie es in einer Ansicht-Modell setzen.)

Meine Faustregel gilt: (sobald ich erkannt, was es mit dem Gedanken über die Frage war) ist, dass gespeicherte Prozeduren Code enthalten sollen, die Datenintegrität innerhalb der Datenbank gewährleistet, ob die gespeicherte Prozedur bestimmter Daten Einfügen, Löschen oder Änderung verbietet oder Marken weitere Änderungen notwendig für die Datenkonsistenz. Business-Logik, insbesondere Logik, die nicht in einer Handvoll von Set-basierten Operationen durchgeführt werden, sollte an anderer Stelle implementiert werden. Datenbanken sind keine Anwendungen. Datenbanken sollte die höchste Autorität für Beziehungen und Einschränkungen, auch wenn die Geschäftsregeln auch an anderer Stelle für umgesetzt werden, beispielsweise die Bereitstellung von Feedback in Code Benutzeroberfläche, die Postbacks von einem Webserver oder beseitigt sonst unnötige Zugriffe auf einem ausgelasteten Server reduziert. Man kann darüber streiten, ob „Datenkonsistenz“ umfasst das Ergebnis einer komplexen Verarbeitung von komplexen Geschäftsregeln, aber ich denke, es ist in der Regel klar, wenn der Kontext verstanden wird. Nicht alle Geschäftsregeln werden als Datenbeziehungen oder Einschränkungen implementiert. Nicht alle Operationen in einer gespeicherten Prozedur sind schneller als Code in einem separaten Prozess ausgeführt wird, sogar auf einem Prozess auf einem anderen Computer über ein Netzwerk ausgeführt wird. Ich habe vor kurzem eine Demonstration zeigt, dass viele Operationen in SSIS, zum Beispiel (INSERT INTO () SELECT FROM) führen schneller in SSIS auf einem separaten Rechner über ein Netzwerk ausgeführt wird als in einer gespeicherten Prozedur ausgeführt wird (das fügt auch die Ergebnisse in eine Datenbank über das Netzwerk). Dies ist ein fast unglaubliches Ergebnis (wo SSIS schneller als rohe SQL-Anweisungen ist), und zeigt, dass die Entdeckung der besten Optimierung aller Performance-Probleme kommt von der Realität (Prüfung) und nicht von der Logik auf nur wenige Konzepte basieren. (Wir müssen noch Entscheidungen treffen, was durch Faustregeln durch Erfahrung gelernt zu testen.) (SSIS ausgeführt schneller durch die automatische Implementierung von Multithreading und Pipelines, BULK INSERT auch wenn es nicht in der rohen SQL-Anweisung angegeben wurde, und Senden von Chargen Einsätze in einem Thread, während der Schaffung zusätzliche Masseneinfügungen auf anderen Threads. In diesem Fall ist es ausgeführt etwa doppelt so schnell wie rohe SQL-Anweisungen.) als ich noch Programmierung und SQL Server-Kurse zu lehren, schien Power Benutzer die Anweisung „Nativer zu haben Treiber bietet den schnellsten Datenzugriff“in ihre Zunge verbrannt, und während es zusätzlich durch gerechtfertigt sein könnte (von ihnen unerkannt) Erklärung, dahinter das Denken ist irreführend.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow