wake-up-neo.com

Argumente für/gegen Business Logic in gespeicherten Prozeduren

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

42
GernBlandston

Gegen gespeicherte Prozeduren: Geschäftslogik im Programmierbereich

Ich lege großen Wert auf Ausdruckskraft und finde den SQL-Raum nicht so aussagekräftig. Verwenden Sie die besten Werkzeuge, die Sie für die am besten geeigneten Aufgaben zur Verfügung haben. Das Spiel mit Logik und Konzepten höherer Ordnung wird am besten auf höchster Ebene durchgeführt. Infolgedessen erfolgt die Bearbeitung von Speicher- und Massendaten am besten auf Serverebene, wahrscheinlich in gespeicherten Prozeduren.

Aber es kommt darauf an. Wenn mehrere Anwendungen mit einem Speichermechanismus interagieren und sicherstellen möchten, dass dessen Integrität und Workflow erhalten bleiben, sollten Sie die gesamte Logik auf den Datenbankserver übertragen. Sie können auch darauf vorbereitet sein, die gleichzeitige Entwicklung in mehreren Anwendungen zu verwalten.

34
Mark Canlas

Ich bin gründlich dagegen. Einer der Hauptgründe ist der erste Grund, den earino angegeben hat - es lebt an einem Ort. Sie können es nicht sehr einfach in die Quellcodeverwaltung integrieren. Es ist so gut wie unmöglich, dass zwei Entwickler gleichzeitig an einem gespeicherten Prozess arbeiten.

Meine andere Hauptbeschwerde ist, dass SQL die komplexe Logik nicht sehr gut darstellt. Sie haben keine Vorstellung vom Gültigkeitsbereich. Code wird in der Regel kopiert, da der Code weniger wiederverwendet werden kann (im Gegensatz zu einer OO Sprache).

Sie müssen Entwicklern Zugriff auf die Datenbank gewähren, damit sie dort entwickeln können. In vielen Organisationen, in denen ich an den Daten gearbeitet habe, befinden sich Menschen in einer anderen Welt als die Entwickler, mit unterschiedlichen Berechtigungen usw. In diesen Fällen wäre es schwieriger, die Entwickler aus der Datenbank herauszuhalten.

23
Nick Van Brunt

Ich bin von der Schule des Denkens, die das sagt, solange Geschäftslogik:

  • lebt in one place
  • wo es richtig dokumentiert ist
  • der ordnungsgemäße Zugriff erfolgt über Dienste, die lose miteinander verbunden werden können
  • durch eine veröffentlichte abstrahierte Schnittstelle

Es ist mir egal, ob die Logik in einer gespeicherten Prozedur, in einer J2EE-Middle-Tier, in einem Clips-Expertensystem oder wo auch immer vorhanden ist. Egal, wo Sie unsere Geschäftslogik ablegen, das "Gesetz zur Erhaltung des Elends" garantiert, dass jemand sagt, es sei die falsche Idee, weil die Komponente/das Repository X gegen die Technologie/Methode Y ausgetauscht werden muss.

19
earino

Einige Gedanken: Bitte beachten Sie, dass dies eine Java-zentrierte Antwort ist, aber der Großteil meiner jüngsten Erfahrung (in den letzten 10 Jahren)

(1) Gleichzeitige Entwicklung durch ein (großes) Entwicklerteam. Wenn Ihre Anwendung so komplex ist, dass nicht jeder Entwickler seine eigene private Version der Datenbank einrichten kann (mit zugehörigen Links/Referenzdaten/etc ...), ist es sehr schwierig, ein vollständiges TEAM von Entwicklern zu haben, an dem alle arbeiten dieselbe Gruppe von PL-SQL-Paketen (zum Beispiel) zur selben Zeit in einer gemeinsam genutzten DEVL-DB gespeichert? Dann stecken Sie (nach meiner Erfahrung) bei der Arbeit in einer Datenbank mit ungültigen Prozeduren/fehlerhafter Zuordnung von Code zu Tabellen, wenn Leute Änderungen vornehmen ...

Als Java-Architekt ist es meiner Meinung nach viel einfacher, wenn jeder Entwickler eine private JBoss-Instanz auf seinem Desktop hat, problemlos an seinen eigenen Funktionen arbeitet und sich in seinem eigenen Tempo einfügt, ohne die anderen zu beeinträchtigen. ..

(2) Continuous Integration-Toolsets Obwohl es in der DB-Welt einige ähnliche "Konzepte" gibt, hat meine Erfahrung gezeigt, dass die Kombination aus (ich wähle hier meine aktuellen Best-of-Breed-Favoriten aus):

  • mVN - Build-System
  • junit - automatisierte Komponententests
  • nexus - repo manager (verwaltet die Lifecycles-Version, Snapshots und Releases von Artefakten)
  • hudson - ci build server
  • sonar - statisches Analysetool/Code-Coverage-Berichte/VIELES mehr

Das Ausführen eines großen Projekts mit all den oben genannten (kostenlosen Tools) ermöglicht eine konsistente/einfache Möglichkeit, die Massen mit XP zu versorgen und Qualitätskontrollen für das gesamte IT-Personal durchzusetzen. Oracle/PL-SQL verfügt nicht über die passenden Toolsets

(3) tools/libraries/etc ... Java hat Zugriff auf eine erstaunliche Reihe von Diensten, die andere Plattformen nicht berühren können - manche kostenlos, manche nicht. Selbst einfache wie log4j (ja, sie haben es für PL/SQL, aber pulease ... es ist nicht annähernd das Gleiche) ermöglichen es Entwicklern, flexibel anpassbare Protokolle zu erstellen, die im laufenden Betrieb geändert werden können (perfekt zum Überspielen). . Automatisierte API-Dokumentation (über Javadoc). Automatisierte Berichterstattung über Einheitentests. Unglaubliche IDEs (Eclipse) mit integrierten Debuggern/Autodeploy auf App-Servern. Eine API für alle Arten von Diensten unter Sun, Open-Source-Bibliotheken für ALLES und 100% ige Unterstützung durch jeden Anbieter

(4) Wiederverwendung von Diensten. Was jemand kommentierte, ist wahr. Wenn Sie schwere datengesteuerte Geschäftsregeln haben, können Sie argumentieren, dass diese in der DB-Schicht leben sollten. Warum? um zu verhindern, dass die mittlere (n) Schicht (en) diese Logik duplizieren müssen.

Dasselbe gilt jedoch auch für Geschäftsregeln, die nicht datengetrieben oder ausreichend komplex sind, sodass OO eine natürlichere Wahl ist . Wenn Sie ALLE Geschäftslogik in die Datenbank einfügen, sind sie nur über die Datenbank verfügbar.

  • Was ist, wenn die Validierung in der Client- oder mittleren App-Ebene durchgeführt werden soll und ein Roundtrip zur DB gespeichert werden soll?
  • Was ist, wenn Sie schreibgeschützte Daten in der mittleren Ebene (aus Leistungsgründen) zwischenspeichern möchten und Geschäftsregeln für die zwischengespeicherten Daten ausführen möchten?
  • Was ist, wenn Sie einen Middle Tier-Service haben, für den kein DB-Zugriff erforderlich ist, oder wenn Sie einen Client haben, der seine eigenen Daten bereitstellen kann?
  • Was ist, wenn der datenabhängige Teil der Geschäftsregeln dann auf externe Services zugreifen muss? Am Ende haben Sie eine fragmentierte Geschäftslogik, die so aussieht:

ich

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 Systeme gesehen, die wie oben beschrieben geschrieben wurden, und mussten sie um 2 Uhr morgens debuggen. Es ist äußerst schwierig, einen kohärenten Überblick über einen komplexen Prozess zu erhalten, wenn die Geschäftslogik in mehrere Ebenen unterteilt ist, und in einigen Fällen ist eine Wartung unmöglich.

13

"Man kann es nicht einfach in die Quellcodeverwaltung integrieren." - Wenn Sie den Code, mit dem der gespeicherte Prozess erstellt wird, in ein Skript einfügen, das versionskontrolliert ist, wird dieser Einwand aufgehoben. Wenn Sie den Ideen von Scott Ambler zu agilen Datenbanken folgen, sollten Sie genau das tun.

Nicht alle Entwickler sind gute Datenmodellierer. Ich kann mir schreckliche Schemata vorstellen, die von Entwicklern erstellt wurden, die dachten, dass sie aufgrund ihrer Kenntnisse von SQL zu Datenbankexperten wurden. Ich denke, es ist sehr wertvoll, wenn Entwickler mit DBAs und Datenmodellierern arbeiten.

Wenn nur eine Anwendung die Datenbank verwendet, kann die Geschäftslogik in der mittleren Ebene angezeigt werden. Wenn viele Apps die Datenbank gemeinsam nutzen, ist es möglicherweise besser, sie in die Datenbank aufzunehmen.

SOA bietet einen Mittelweg: Dienste besitzen ihre Daten. Nur der Dienst hat Zugriff auf die Daten. Um an Daten zu gelangen, müssen Sie den Dienst durchlaufen. In diesem Fall ist es möglich, die Regeln an einer beliebigen Stelle zu platzieren.

Anwendungen kommen und gehen, aber Daten bleiben.

11
duffymo

Ein Grund mehr, Geschäftslogik NICHT in Sprocs zu speichern - eingeschränkte Skalierungsmöglichkeiten der DB. Es kommt sehr häufig vor, dass Ihre Datenbank Ihr Engpass ist. Aus diesem Grund ist es empfehlenswert, die Datenbank so stark wie möglich zu belasten.

8
edgi

Meine wenigen Beobachtungen:

Für gespeicherte Prozeduren:

  • nach einiger Zeit des Projektlebens ist der Engpass in den meisten Fällen die Datenbank und nicht der Webserver - und gespeicherte Prozeduren sind viel, viel schneller

  • die Verwendung von SQL Profiler mit ORM-generierten SQL-Abfragen ist sehr schwierig. Dies ist mit gespeicherten Prozeduren einfach

  • sie können ein Update für gespeicherte Prozeduren sofort ohne ein Dienstfenster bereitstellen

  • aus Performancegründen ist es einfacher, eine gespeicherte Prozedur zu optimieren als ORM-Code

  • möglicherweise haben Sie viele Anwendungen, die dieselben DB-/gespeicherten Prozesse verwenden

  • jedes komplexe Datenszenario ist eine Abstimmung für gespeicherte Prozeduren

Für Bewerbung/ORM:

  • sie können das Code-Repository verwenden (mit gespeicherten Prozessen ist es immer noch möglich, aber teuer)

  • Java/C # -Sprache ist ein besseres Werkzeug, um Geschäftslogik auszudrücken

  • Java/c # ist einfacher zu debuggen (mit Ausnahme des dynamisch generierten ORM-SQL)

  • unabhängigkeit der Datenbank-Engine (dies ist jedoch nicht sehr wahrscheinlich, dass ein Projekt die Datenbank in eine andere ändert)

  • ORM bietet ein Datenmodell, das einfach zu bedienen ist

Meiner Meinung nach: für große Projekte - für gespeicherte Prozeduren, für die anderen - wird Application/ORM gut funktionieren.

Am Ende eines Tages kommt es nur noch auf die Datenbank an.

7
chrisb

Geschäftslogik sollte an einem Ort gekapselt werden. Wir können garantieren, dass die Logik immer ausgeführt und konsistent ausgeführt wird. Durch die Verwendung von Klassen, die von allen Aktivitäten, die eine Entität in der Datenbank betreffen, durchlaufen werden müssen, können wir sicherstellen, dass alle Überprüfungen ordnungsgemäß ausgeführt werden. Es gibt eine Stelle für diesen Code, und jeder Entwickler im Projekt kann diese Klasse leicht öffnen und die Logik sehen (da die Dokumentation veraltet sein kann und wird, ist der Code die einzige zuverlässige Form der Dokumentation).

Dies ist mit gespeicherten Prozeduren nur schwer möglich. Möglicherweise haben Sie mehr als einen Sproc, der sich mit derselben Tabelle (n) befasst. Das Verketten mehrerer Sprocs, sodass sich die Logik nur in einem befindet, wird unhandlich. Das ist Streik eins. Wie bestimmen Sie "Was sind alle Geschäftsregeln, die Entität X umgeben" in der Datenbank? Viel Spaß beim Durchsuchen von Tausenden von Sprocs, die versuchen, dies aufzuspüren.

Nummer zwei ist, dass Sie Ihre Geschäftslogik an Ihren Persistenzmechanismus binden. Möglicherweise speichern Sie nicht alle Ihre Daten in derselben Datenbank, oder einige befinden sich in XML usw. Diese Art von Inkonsistenz ist für den Entwickler schwierig.

Die Validierung ist schwierig durchzuführen, wenn sich die Logik nur in der Datenbank befindet. Rufen Sie wirklich einen Sproc auf, um jedes Feld in Ihrem Dateneingabeformular zu validieren? Validierungsregeln und Geschäftslogik sind enge Verwandte. Diese Logik sollte alle am selben Ort durchgeführt werden!

5
Jim Petkus

Es gibt ein Sprichwort...

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

Meiner bescheidenen Meinung nach gibt es keine Antwort, die allen Umständen gerecht wird. Es scheint mir, dass viele Leute einfach annehmen, dass das Einfügen von Business Logic in die Datenbank immer falsch ist.

Es wurde viel Arbeit geleistet, um die Transaktionsverarbeitung, insbesondere Massenvorgänge, auf Datenbankseite sehr effizient zu gestalten. Auch das Code-Management in Datenbanken hat sich stark verbessert, seit die meisten Meinungen gegen Datenbanken gebildet wurden.

Ich halte es für falsch, den Datenbankserver nur als Persistenzschicht zu betrachten. Wenn Ihre Verarbeitungsaktivitäten auf dem DB-Server am effizientesten sind, führen Sie sie dort aus.

Wenn nicht, machen Sie sie woanders.

Es kommt darauf an, was am besten zu der Anwendung passt, an der Sie gerade arbeiten, zu dem Team, mit dem Sie zusammenarbeiten, und zu dem Kunden, der Sie eingestellt hat.

Das sind nur meine 2 Cent.

4

+: SQL Server optimiert manchmal den Code

+: Sie sind gezwungen, Parameter zu übergeben, wodurch SQL-Injection-Probleme eingeschränkt werden

-: Ihr Code hängt von einer einzelnen Datenbank ab (einige Datenbanken haben nicht einmal SP)

-: Um den Code zu ändern, müssen Sie eine Verbindung zur Datenbank herstellen

-: Logik ist nicht gut organisiert

Persönlich bin ich dagegen, aber ich musste es einmal auf einer sehr geschäftigen Website verwenden. Die Verwendung von SP in MS SQL brachte enorme Vorteile, aber als ich das Zwischenspeichern implementiert hatte, waren diese Vorteile nicht mehr so ​​groß.

4
Spikolynn

Sie können die Geschäftslogik in einer Geschäftslogik-Schicht testen. Wenn es vollständig getrennt ist, können die Beständigkeitsoperationen verspottet werden, sodass Sie nur die BL testen. Ein gespeicherter Prozess ist weitaus schwieriger zu warten/zu debuggen/zu testen als z. linq und c #.

2
Jon smith

DBMS! = Anwendungsserver

  • Funktionsprogrammierung (DB Stored Procedure) vs OOP. Für große Programme ist OOP nur Standard.
  • IDE - Eclipse, Intellij, Netbeans mit allen Plugins zum Debuggen, Testen und Analysieren funktionieren nur mit echten Programmiersprachen. Statische Code-Tools .
  • Versionskontrolle, falls Sie eine für PLSQL & Co. erhalten. ist toll. Wenn Sie "Ansicht synchronisieren" direkt von Ihnen erhalten IDE - sind Sie wirklich der Glückliche.
  • Skalieren Sie Ihr System. Für DB-System ist die Hölle. Sie benötigen teure Hardware für andere "Knoten". Replikation. Und wahrscheinlich Lizenz für jeden Knoten. Vergessen Sie nicht, dass Sie sich immer noch in der "funktionalen Programmierung" befinden und die Bemühungen, solche Systeme zu verstehen und zu warten, viel größer sind.
  • Sie stecken in Ihrer Datenbank fest, versuchen, eine andere Datenbank zu ändern oder eine neue hinzuzufügen
  • Und so weiter...

Gespeicherte Prozeduren für Geschäftslogik sind heute keine gute Praxis. Verwenden Sie stattdessen die 3-Tier-Architektur.

1
Webaib

Es gibt verschiedene Arten von "Geschäftslogik". Ziehen Sie in Betracht, die Partitionierung basierend auf den Beziehungen zu anderen Ebenen oder Diensten vorzunehmen. Hier sind einige Faustregeln aus MVC-Sicht:

a) In der Datenbank (gespeicherte Prozedur), wenn sie sich hauptsächlich auf Daten bezieht und mit Verknüpfungen und relativ einfachen WHERE- und SELECT-Klauseln ausgeführt werden kann.

b) In der Steuerung, wenn es sich hauptsächlich um Routing oder Dispatching handelt; Dies ist eine umfangreichere Flusskontrolle der Benutzeroberfläche im Hinblick auf die Auswahl von Bildschirmen oder Ressourcen.

c) Im Modell oder Ansichtsmodell, wenn es sich um komplexe oder komplizierte Berechnungen und/oder Bedingungen handelt.

d) In der Ansicht (wie Razor) ist es in erster Linie ein Anzeigeproblem, wie "freundliche" Neuformatierung und relativ einfach zu implementieren. (Wenn es komplex ist, können Sie es in ein Ansichtsmodell einfügen.)

0
FloverOwe

. @ Nick: „Ich bin durchaus dagegen Einer der größten Gründe, warum der erste Grund earino angegeben ist -. Es an einem Ort lebt, Sie können es nicht sehr leicht in die Quellcodeverwaltung integrieren Es ist fast unmöglich ist, zwei Devs haben auf eine Arbeits. gespeicherte Prozedur zur gleichen Zeit. "

Nicht, dass ich dafür plädiere, Geschäftslogik für gespeicherte Prozeduren zu verwenden (im Gegenteil). Aber diese von Ihnen vorgebrachten Gründe ergeben keinen Sinn. 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 bei den IT-/Bereitstellungs-Liasons) Ein oder mehrere Entwickler können an derselben gespeicherten Prozedur außerhalb der Quellcodeverwaltung arbeiten, genau wie Sie es mit einfachem alten Quellcode tun - durch Verzweigen, Versionsverwaltung und Zusammenführen.

Wenn die einzige Kopie der gespeicherten Prozedur (und der Pakete, die sie enthalten) nur in der Datenbank vorhanden ist, können Sie dies natürlich nicht mit der Quellcodeverwaltung (und allen damit verbundenen Problemen) steuern. Dies ist jedoch kein Problem der gespeicherten Prozedur, sondern ein Problem der Unfähigkeit, diesen Code zu verwenden. Es ist ebenso ein Zeichen der Unfähigkeit, als würde nur eine Kopie Ihres Quellcodes von der Produktion leben.

Ich habe in Systemen mit sehr viel Code gearbeitet, sowohl Java als auch PLSQL/DDLs, und sie wurden alle in Clearcase versioniert. Sie wurden alle als Quellcode behandelt, der nach einem strengen Verfahren kompiliert und bereitgestellt wurde, wobei verschiedene Teams daran arbeiteten. Hatte noch nie ein Problem mit dem, was du beschreibst.

Es gibt kontextspezifische Gründe, Geschäftslogik nicht in gespeicherte Prozeduren einzufügen, aber diese sind nicht gültig.

0
luis.espinal

Die Leistung wird massiv verbessert, indem Logik in die gespeicherten Prozesse verschoben wird, insbesondere wenn explizite Transaktionen beteiligt sind.

Nach meiner Erfahrung sind Anwendungsentwickler nicht sehr gut darin, optimierten Datenbankcode zu schreiben, und denken nicht an Parallelitäts- oder Leistungsprobleme.
Wenn die Geschäftslogik in der Anwendungsschicht beibehalten wird, müssen Sie in der Regel große Datenmengen (häufig bei vielen Roundtrips) über das Netzwerk verschieben, im Speicher des DB-Servers duplizieren und mindestens einmal Führen Sie auf dem App-Server eine zeilenweise Verarbeitung in der App durch, während Sie eine Transaktion geöffnet halten. Dann beschweren sich die App-Entwickler, dass die Datenbank langsam ist und weiterhin blockiert.

Wenn Sie die Logik in die Datenbank einfügen, wo immer dies möglich ist, geben Sie in der Regel nur einige Parameter im Netzwerk weiter, Transaktionen werden nicht gehalten, während Sie auf Netzwerkressourcen warten, und das Ganze wirkt wie geschmierter Blitz. Datenbanken sollten natürlich wie jeder andere Quellcode in die Quellcodeverwaltung gehen. Dafür gibt es jede Menge Tools.

0
Rich Cain

Meine Faustregel (nachdem ich erkannt hatte, worum es sich bei der Frage handelte) lautet, dass gespeicherte Prozeduren Code enthalten sollten, der die Datenintegrität in der Datenbank gewährleistet, ob die gespeicherte Prozedur das Einfügen, Löschen oder Ändern bestimmter Daten verbietet oder andere Änderungen erforderlich macht für Datenkonsistenz. Geschäftslogik, insbesondere Logik, die nicht in einer Handvoll satzbasierter Operationen implementiert werden kann, sollte an anderer Stelle implementiert werden. Datenbanken sind keine Anwendungen. Datenbanken sollten die ultimative Autorität für Beziehungen und Einschränkungen sein, auch wenn die Geschäftsregeln an anderer Stelle implementiert sind, z. B. für die Bereitstellung von Feedback im Benutzeroberflächencode, mit dem Postbacks von einem Webserver reduziert oder ansonsten unnötige Zugriffe auf einen ausgelasteten Server vermieden werden. Man kann sich darüber streiten, ob "Datenkonsistenz" das Ergebnis einer komplexen Verarbeitung komplexer Geschäftsregeln beinhaltet, aber ich denke, dass es normalerweise klar ist, wenn der Kontext erst einmal verstanden ist. Nicht alle Geschäftsregeln werden als Datenbeziehungen oder Einschränkungen implementiert. Nicht alle Vorgänge in einer gespeicherten Prozedur sind schneller als Code, der in einem separaten Prozess ausgeführt wird, selbst in einem Prozess, der auf einem separaten Computer in einem Netzwerk ausgeführt wird. Ich habe kürzlich eine Demonstration durchgeführt, die zeigt, dass viele Vorgänge in SSIS (INSERT INTO () SELECT FROM) beispielsweise in SSIS, das über ein Netzwerk auf einem separaten Computer ausgeführt wird, schneller ausgeführt werden als in einer gespeicherten Prozedur (bei der die Ergebnisse auch in eine Datenbank eingefügt werden) über das Netzwerk). Dies ist ein fast unglaubliches Ergebnis (wobei SSIS schneller ist als unformatierte SQL-Anweisungen) und zeigt, dass die Entdeckung der besten Optimierung von Leistungsproblemen aus der Realität (Testen) und nicht aus der Logik resultiert, die auf nur wenigen Konzepten basiert. (Wir müssen noch Entscheidungen darüber treffen, was anhand von Faustregeln getestet werden soll.) (SSIS wird schneller ausgeführt, indem Multithreading und Pipelines automatisch implementiert, BULK INSERT verwendet, auch wenn dies nicht in der SQL-Rohanweisung angegeben ist, und Stapel gesendet werden von Einfügungen in einem Thread, während zusätzliche BULK INSERTs in anderen Threads erstellt wurden. In diesem Fall war die Leistung etwa doppelt so hoch wie bei SQL-Anweisungen.) Als ich Programmier- und SQL Server-Kurse unterrichtete, schienen PowerBuilder-Benutzer die Anweisung "Native" zu haben Treiber bieten den schnellsten Datenzugriff ", der in ihre Sprache eingebrannt ist, und obwohl dies durch zusätzliche (von ihnen nicht erkannte) Erklärungen gerechtfertigt sein könnte, ist das dahinter stehende Denken irreführend.

0
Joe Ferry

Projekte mit hohem Budget: Wenn Sie Ihre aktuellen Daten im Speicher behalten und die Änderungen regelmäßig auf der Festplatte speichern, möchten Sie die Geschäftslogik unabhängig vom Datenbankserver verwalten. Anwendungsfall: Daten von RAM-Servern, komplexe Caching-Mechanismen.

Low-Budget-Projekte: Wenn Sie die aktuellen Daten auf der Festplatte speichern und Ihre Präsentation von Festplattenlesevorgängen abhängt, können Sie durch die Verarbeitung der Geschäftslogik in gespeicherten Prozeduren Entwicklungszeit sparen. Anwendungsfall: Daten von der Festplatte bereitstellen

0