Verstoßen gespeicherte Prozeduren gegen die dreistufige Trennung?

41

Einige meiner Kollegen haben mir mitgeteilt, dass das Vorhandensein von Geschäftslogik in gespeicherten Prozeduren in der Datenbank die dreistufige Trennungsarchitektur verletzt, da die Datenbank zur Datenschicht gehört, während gespeicherte Prozeduren Geschäftslogik sind.

Ich denke, die Welt wäre ein sehr düsterer Ort ohne gespeicherte Prozeduren.

Verstoßen sie wirklich gegen die dreistufige Trennung?

Tulains Córdova
quelle
9
Fragen Sie sie einfach, haben sie nicht von der 3 1/2 Tier-Architektur gehört ...
Dreza
7
Denken Sie daran, dass Ebenen und Ebenen nicht ein und dasselbe sind.
NoChance
2
@ emmad-kareem Diese Frage hat mir geholfen ( stackoverflow.com/questions/120438/… ). Das Problem ist, dass die spanische Sprache (meine Muttersprache) in der Fachliteratur ein einziges Wort verwendet ("capa"), während Englisch zwei sehr unterschiedliche Wörter hat.
Tulains Córdova
1
@ user1598390, Sie haben Recht, es könnte besonders verwirrend werden, dass die Welt der Software nicht streng genug ist, wenn es um Definitionen in einer Sprache geht, geschweige denn in mehreren Sprachen.
NoChance
1
3-Tier-Architektur ist ein logisches Konzept, kein physikalisches Konzept. Sie können Geschäftsregeln mithilfe gespeicherter Prozeduren implementieren. Diese gespeicherten Prozeduren befinden sich zwar physisch in der Datenbank, sind jedoch immer noch Teil der Geschäftslogikschicht.
Craig

Antworten:

33

Ihre Kollegen verbinden Architektur mit Implementierung.

Die Idee hinter einer mehrschichtigen Anwendung ist einfach, dass sie in Teile zerlegt ist, die bestimmte Arten der Verarbeitung (Speicherung, Geschäftslogik, Präsentation) einschließen und über gut definierte Schnittstellen miteinander kommunizieren. So wie es möglich ist, Dinge, die einer objektorientierten Programmierung ähneln, in nicht-objektorientierten Sprachen erfolgreich durchzuführen, ist es auch möglich, dasselbe mit mehreren Ebenen in einer Umgebung, z. B. einem Datenbankserver, zu tun. Beiden gemeinsam ist die Notwendigkeit von Sorgfalt, Disziplin und Verständnis für die damit verbundenen Kompromisse.

Schauen wir uns eine dreistufige Anwendung an, bei der zwei der Ebenen in einer Datenbank implementiert wurden:

  • Datenebene: Besteht aus Datenbanktabellen zugegriffen mit den vier Standard - Tabellenoperationen ( INSERT, UPDATE, DELETEund SELECT).
  • Logikschicht : Besteht aus gespeicherten Prozeduren, die nur Geschäftslogik implementieren und auf die Datenschicht nur mit den oben beschriebenen Methoden zugreifen.
  • Präsentationsebene: Besteht aus einem Webserver, auf dem Code ausgeführt wird, der auf die Logikebene zugreift, indem nur gespeicherte Prozeduraufrufe ausgeführt werden.

Dies ist ein durchaus akzeptables Modell, das jedoch einige Nachteile mit sich bringt. Die Geschäftslogik ist so implementiert, dass sie einen schnellen und einfachen Zugriff auf die Datenebene ermöglicht und möglicherweise Dinge ermöglicht, die von einer Logikebene außerhalb der Datenbank "auf die harte Tour" ausgeführt werden müssten. Was Sie aufgeben, ist die Möglichkeit, auf einfache Weise eine der beiden Ebenen auf ein anderes technologisches Element zu verlagern und diese problemlos zu implementieren (dh Sie müssen besonders darauf achten, dass die Ebenen keine in der Datenbank verfügbaren Funktionen verwenden, die sich jedoch außerhalb ihrer definierten Schnittstellen befinden). .

Ob diese Art von Dingen und die damit verbundenen Kompromisse in einer bestimmten Situation akzeptabel sind, müssen Sie und Ihre Kollegen anhand Ihres Urteils feststellen.

Blrfl
quelle
2
Also kann ich ihnen sagen, dass gespeicherte Prozeduren Teil der Logikschicht sind, was die Architektur betrifft, unabhängig davon, ob sie in der Datenbank gespeichert sind oder nicht?
Tulains Córdova
3
@ user1598390: ja. Obwohl es Schicht wäre, 3-Schicht und nicht 3-Schicht zu sagen.
Jmoreno
4
@ user1598390: Das kannst du sagen, solange du es beweisen kannst. Wenn die Präsentationsschicht zum ersten Mal SELECTdirekt aus Tabellen (der Datenschicht) stammt, wurde das Modell beschädigt.
Blrfl
@blrfl Darum habe ich mich gekümmert;)
Tulains Córdova
2
@ user1598390: das ist in Ordnung, denke nur daran, dass das Ziel die logische Trennung von Bedenken ist und nicht, dass Dinge auf andere Hardware gestellt werden.
Jmoreno
19

Gespeicherte Prozeduren sind leistungsstark genug, um einen Verstoß gegen die dreistufige Trennung zu codieren, indem Geschäftslogik in die RDBMS-Schicht übernommen wird. Dies ist jedoch Ihre Entscheidung und kein inhärenter Fehler gespeicherter Prozeduren. Sie können Ihre SPs auf die Erfüllung der Anforderungen Ihrer Datenschicht beschränken, während Ihre Anwendungslogik in der Anwendungsschicht Ihrer Architektur bleibt.

Es gibt eine seltene, aber wichtige Ausnahme von der Trennungsregel, wenn Sie gespeicherte Prozeduren (insbesondere eine Gruppe von Triggern) zum Enthalten von Geschäftslogik benötigen. Dies ist der Fall, wenn Ihre Anwendung viele spontane Datenaggregationen erstellen muss, die Millionen von Zeilen betreffen. In solchen Fällen können Trigger eingerichtet werden, um voraggregierte Daten für die Verwendung der Business-Schicht zu verwalten. Dies sollte nur in Situationen erfolgen, in denen Ihre Anwendung ohne Voraggregation unannehmbar langsam ist.

dasblinkenlight
quelle
7
+1 für die Erwähnung, dass gelegentlich aus Leistungsgründen Logik in der Datenbank gespeichert werden soll, da ein RDBMS in der Regel Vorgangsgrößenordnungen schneller festlegt als Ihr Anwendungscode. Obwohl dies offensichtlich nur dann der Fall ist, wenn die Leistung von entscheidender Bedeutung ist und im App-Code nicht erreicht werden kann, handelt es sich bei der überwiegenden Mehrheit der modernen datenbankgestützten Apps um CRUD-Apps, für die keine Verwendung erforderlich ist.
Jimmy Hoffa
1
Amen. Die Leute scheinen zu denken, dass Sprocs = Business "Code". Sie sollten als DB-API betrachtet werden, und dann sind sie viel sinnvoller. Natürlich können sie auch Randfälle beheben, bei denen Sie Leistung von Ihrer Logik auch benötigen!
Gbjbaanb
5

Der Rat von Atwood aus dem Jahr 2004 ist bis heute gültig, nur haben wir jetzt auch den Vorteil von ORM.

http://blog.codinghorror.com/who-needs-stored-procedures-anyways/

Gespeicherte Prozeduren sollten als Datenbankassemblersprache betrachtet werden: Nur zur Verwendung in den leistungskritischsten Situationen. Es gibt viele Möglichkeiten, eine solide Datenzugriffsebene mit hoher Leistung zu entwerfen, ohne auf gespeicherte Prozeduren zurückzugreifen. Sie werden eine Menge Vorteile erkennen, wenn Sie sich an parametrisiertes SQL und eine einzige zusammenhängende Entwicklungsumgebung halten.

Patrick Szalapski
quelle
In meiner 20-jährigen Erfahrung in einem großen Unternehmen werden gespeicherte Prozeduren weder für die Rückgabe von Zeilen (dafür werden Ansichten verwendet) noch für einfache Einfügungen oder Aktualisierungen (dafür wird Inline-SQL verwendet) verwendet. Sie werden hauptsächlich für lange Vorgänge verwendet, für die keine Benutzerinteraktion erforderlich ist, und für das zeilenweise Zusammenfassen und Durchführen von Einfügungen oder Aktualisierungen, die auf einer bestimmten Geschäftslogik basieren, z . Der Autor des Artikels scheint gespeicherte Prozeduren verwendet zu haben, um Zeilen zurückzugeben, und deshalb heizt er sie auf.
Tulains Córdova
3

Kurze Zusammenfassung: Es hängt wirklich von der Verwendung der gespeicherten Prozeduren und den Geschäftsanforderungen ab.

Es gibt eine Reihe von Projekten, die eine dreistufige Architektur verwenden, und je nach Art der Geschäftsanforderungen müssen möglicherweise einige Vorgänge auf eine Datenebene verlagert werden .

Apropos Terminologie, in allgemeinen Worten, diese Ebenen beschrieben als:

  • Die Präsentationsebene oder Benutzerdienstebene - ermöglicht einem Benutzer den Zugriff auf die Anwendung.
  • Die mittlere Schicht oder Business Services-Schicht besteht aus Geschäfts- und Datenregeln.
  • Die Datenschicht oder Datendienstschicht interagiert mit persistenten Daten, die normalerweise in einer Datenbank oder in einem permanenten Speicher gespeichert sind.

Normalerweise besteht die mittlere Schicht oder die Schicht der Geschäftsdienste für die angegebene Architektur aus Geschäfts- und Datenregeln. Manchmal macht es jedoch einen großen Unterschied, schwere Basisoperationen und / oder Datenregeln, die in der Datenschicht ausgeführt werden sollen, durch gespeicherte Prozeduren zu verschieben.

Die Vorteile dreistufiger Designs sind:

Während des Lebenszyklus einer Anwendung bietet der dreistufige Ansatz Vorteile wie Wiederverwendbarkeit, Flexibilität, Verwaltbarkeit, Wartbarkeit und Skalierbarkeit. Sie können die von Ihnen erstellten Komponenten und Dienste freigeben und wiederverwenden und sie bei Bedarf über ein Computernetzwerk verteilen. Sie können große und komplexe Projekte in einfachere Projekte unterteilen und sie verschiedenen Programmierern oder Programmierteams zuweisen. Sie können auch Komponenten und Dienste auf einem Server bereitstellen, um mit den Änderungen Schritt zu halten, und Sie können sie erneut bereitstellen, wenn sich die Benutzerbasis, die Daten und das Transaktionsvolumen der Anwendung erhöhen.

Es ist also wirklich ein fallbasierter Ansatz, der Kompromisse in sich birgt. In den Microsoft-Entwurfsrichtlinien für das dreistufige Architekturmodell wird jedoch empfohlen, die Geschäftslogik auf der mittleren Ebene zu belassen.

EL Yusubov
quelle
2

Schicht bedeutet tatsächlich unterschiedliche Maschine, Schicht bedeutet unterschiedliche logische Trennung. Bei gespeicherten Prozeduren befinden sich die Datenschicht und (zumindest ein Teil davon) die Geschäftslogikschicht auf derselben Ebene. Das Einfügen der Geschäftslogik in die gespeicherten Prozeduren verletzt die dreischichtige Architektur, ist jedoch fraglich, ob sie eine dreischichtige Architektur verletzt. Eine sichere Sache ist, dass es kein gutes Beispiel für die Trennung von Bedenken ist.

Eine Ebene ist ein logischer Strukturierungsmechanismus für die Elemente, aus denen Ihre Softwarelösung besteht. Eine Schicht ist ein physikalischer Strukturierungsmechanismus für die Systeminfrastruktur. ( Referenz )

Meiner Meinung nach gibt es zwei Hauptprobleme beim Erstellen der Geschäftslogik in der Datenbank:

  1. Code und Bibliotheken: Sie werden weniger Programmierer finden, die in der Lage sind, in SQL, PL / SQL, TSQL usw. zu programmieren als in C #, Java usw. Programmiersprachen haben auch den Vorteil großartiger IDEs, großartiger Bibliotheken und Frameworks.

  2. Horizontale Skalierbarkeit: Sie können Ihr System nur skalieren, indem Sie den physischen Server, auf dem sich die Datenbank befindet, durch einen leistungsstärkeren Server ersetzen, der ziemlich teuer ist (ein Server mit 64 GB RAM). relationale Datenbanken lassen sich horizontal sehr schlecht skalieren, und das sogar mit höheren Kosten. Während mit Geschäftslogik in OO-Servern eine horizontale Skalierung möglich ist, können Sie den Server auf viele Knoten stellen (in Java wird dies von vielen Anwendungsservern unterstützt).

m3th0dman
quelle
-1

Wir hatten diese Debatte vor einiger Zeit in unserem Büro, ich habe die Datenbankentwicklung favorisiert, ich habe folgende Ansicht dazu

  1. Wenn Sie Oracle Database verwenden, sollten Sie so oft wie möglich PL / SQL verwenden. Denn Unternehmen, die investieren, werden sich mit Sicherheit noch mindestens 10 Jahre an Oracle halten. Während Sie gestern in den Anwendungen Oracle Forms, heute .net Web Forms, dann MVC und morgen Angularjs verwendet haben, benötigen Sie nur restfull apis. Wenn sich Ihre maximale Logik in der Datenbank befindet, können Sie problemlos auf die neuen Front-End-Technologien migrieren.
  2. Die Datenbankentwicklung ist sehr schnell und in Bezug auf die Leistung sehr effizient. Nur um Ihnen eine Perspektive zu geben. In unserem Projekt gab es 7 Anwendungsentwickler und einen Datenbankentwickler, und 80% der Logik befanden sich in der Datenbank.
  3. Wenn Sie Oracle verwenden, können Sie Dienstprogramme verwenden, um Ihre Datenbankprozeduren direkt in Res full Api zu konvertieren.

Das stärkste Argument der Anwendungsentwickler ist, dass die Geschäftslogik unabhängig von der Datenbank sein sollte, damit Sie die Datenbank problemlos ändern können. Ich denke, wenn ein Unternehmen Oracle verwendet, warum es stattdessen auf eine andere Technologie umsteigt, sind die Chancen, dass die Anwendungslogik veraltet ist, größer. Das Problem ist, dass meistens neue Talente der Datenbankressource fehlen. Meistens beginnen die Leute mit einfachen Websites, auf denen sie MySQL oder SQLServer verwenden. Diese Jungs werden dann zu Senior-Leads und haben eine emotionale Bindung zur Anwendungsebene :) Sie wollen nicht einmal verstehen oder debattieren.

Farhan Ali
quelle
"Wenn Sie Oracle Database verwenden, sollten Sie so oft wie möglich PL / SQL verwenden." Gespeicherte Prozeduren erhöhen die Auslastung des normalerweise flaschenhalsigsten und schwer skalierbaren Systems in einer Architektur. Sie sind auch aus Sicht der Versionskontrolle und des Komponententests schwierig zu managen. "Denn mit Sicherheit werden Unternehmen, die investieren, in mindestens zehn Jahren noch am Orakel festhalten." Das ist nur Unsinn. Was bringt dich dazu, das zu denken? Wenn Sie Ihr System mit dummem PL / SQL-Verfahrensmüll füllen, können Sie ein Unternehmen davon abhalten, auf etwas Zeitgemäßes umzusteigen. Das könnte wahr sein.
JimmyJames