it-swarm.com.de

Vor- und Nachteile der Speicherung der gesamten Geschäftslogik in gespeicherten Prozeduren in Webanwendungen

In einigen Organisationen, für die ich gearbeitet habe, werden Webanwendungen entwickelt, die auf der gesamten Geschäftslogik in gespeicherten Datenbankprozeduren basieren. Verwenden Sie beispielsweise HTML für Ansicht und Servlet als Controller, um die Clientanforderung an die entsprechenden gespeicherten Datenbankprozeduren umzuleiten.

Was sind die Vor- und Nachteile dieser Art von Designs? Meiner Meinung nach, wenn die Geschäftslogik stark von der Datenbank abhängt, dann folgen Sie besser dieser Art von Design !!!!!

40
droidsites

Theoretisch sind die Vor- und Nachteile wie folgt:

Vorteile:

  1. Ein Ort, an dem die gesamte Geschäftslogik enthalten ist
  2. Möglicherweise schnellere Anwendungen, da mehrere SQL-Abfragen und dergleichen in einem "Roundtrip" zur Datenbank ausgeführt werden können
  3. Trivial, um die gespeicherten Prozeduren aus mehreren Anwendungen zu nutzen

Nachteile:

  1. Für die Leistungsoptimierung ist ein DBA erforderlich
  2. Alle Entwickler müssen sich mit Ihrem speziellen SQL-Dialekt (T-SQL, Pl/SQL usw.) sehr gut auskennen.
  3. SQL-Code ist nicht so aussagekräftig und daher schwieriger zu schreiben, wenn übergeordnete Konzepte behandelt werden, die nicht wirklich mit Daten zusammenhängen
  4. Viel mehr unnötige Belastung der Datenbank

Praktisch gesehen hätte nur ein Narr die gesamte Geschäftslogik in der Datenbank.

  1. Nur sehr wenige Entwickler können eine konsistente Schnittstelle für gespeicherte Prozeduren erstellen, die problemlos für alle Anwendungen geeignet ist. Normalerweise liegt dies daran, dass bestimmte Annahmen von dieser aufrufenden Anwendung gemacht werden
  2. Gleiches gilt für die Dokumentation all dieser gespeicherten Prozeduren
  3. Datenbankserver sind im Allgemeinen so eng wie sie sind. Wenn Sie sie unnötig belasten, wird dieser Engpass noch weiter verringert. Für alles, was über ausreichend Verkehr verfügt, sind ein komplizierter Lastausgleich und eine leistungsfähige Hardware erforderlich
  4. SQL ist kaum eine Programmiersprache. Ich hatte einmal das Vergnügen, eine Skript-Engine zu verwalten, die als gespeicherte T-SQL-Prozedur geschrieben wurde. Es war langsam, fast unmöglich zu verstehen und es dauerte Tage, um eine triviale Erweiterung in den meisten Sprachen zu implementieren
  5. Was passiert, wenn Sie einen Client haben, dessen Datenbank einen anderen SQL Server ausführen muss? Sie müssen grundsätzlich von vorne anfangen - Sie sind sehr an Ihre Datenbank gebunden. Gleiches gilt, wenn Microsoft beschließt, einige Funktionen, die Sie ein paar hundert Mal für Ihre gespeicherten Prozeduren verwenden, zu verwerfen
  6. Die Quellcodeverwaltung ist mit gespeicherten Prozeduren äußerst schwierig durchzuführen, insbesondere wenn Sie viele davon haben
  7. Datenbanken sind schwer synchron zu halten. Was ist, wenn Sie einen Konflikt zwischen zwei Entwicklern haben, die gleichzeitig in der Datenbank arbeiten? Abhängig von Ihrem Setup für die "Entwicklungsdatenbank" überschreiben sie sich gegenseitig den Code, ohne es wirklich zu wissen
  8. Die Tools sind definitiv weniger einfach zu bedienen, unabhängig davon, welche Datenbank-Engine Sie verwenden.

Also, um die Frage objektiv zu beantworten. In den meisten Fällen werden gespeicherte Prozeduren nur in einigen Fällen benötigt. Wenn Sie beispielsweise einen Bericht erstellen müssen, in dem Sie viele bedingte Verarbeitungen in mehreren großen Tabellen durchführen müssen, möchten Sie nicht, dass Ihre Anwendung ein paar hundert SQL-Abfragen an die Datenbank sendet. Sie möchten eine gespeicherte Prozedur erstellen, damit der Overhead der Netzwerkverzögerung nicht auftritt. Und normalerweise möchten Sie gespeicherte Prozeduren nur dann erstellen, wenn Clients eine benutzerdefinierte Abfrage in Ihrer Datenbank ausführen möchten. Gespeicherte Prozeduren und Ansichten können dies leicht ermöglichen, ohne dass Ihre Kunden ein Datenbank-Experte sind.

62
Earlz

Nachteile :

  • Die Datenbank ist der am wenigsten skalierbare Teil Ihrer Architektur.
  • Insbesondere in Zeiten von Webdiensten und REST-fähigen Webanwendungen von Drittanbietern können Sie nicht Ihre gesamte Geschäftslogik in gespeicherten Prozessen enthalten.
  • SQL-Implementierungen variieren, einige können schwierig sein und keine kann so flüssig gelesen werden wie eine erstklassige Programmiersprache auf Anwendungsebene.
    • Denken Sie daran, dass Code viel häufiger gelesen als geschrieben wird .
16
Jim G.

Vorteile des Haltens der gesamten Geschäftslogik für gespeicherte Prozeduren in Webanwendungen für :

  • Ein Ort ist leichter zu pflegen als mehrere
  • Datenbanken sind schnell und optimiert und können gut skaliert werden.
  • Dieselben Prozeduren können aus mehreren, verschiedenen Frameworks und Sprachen aufgerufen werden.
  • Die Logik ist in bestimmten Anwendungen von der Implementierung entkoppelt.
  • Nacharbeiten für das Ändern von Anwendungen können reduziert werden, wenn die Datenbank gleich bleibt.

Nachteile des Haltens der gesamten Geschäftslogik für gespeicherte Prozeduren in Webanwendungen: gegen :

  • Gute SQL-Kenntnisse sind an vielen Orten schwer zu finden.
  • Gute SQL-Codierer können teuer sein.
  • Alle Anwendungsentwickler müssen in der Lage sein, diese entweder zu ändern oder eine schnelle Änderung anzufordern.
  • Einige Daten, die für eine SQL-Datenbank weniger gut geeignet sind, z. Bilddaten oder Dokumentdaten sind möglicherweise nicht in der Datenbank verfügbar und es kann schwierig sein, sie in die gespeicherten Prozeduren zu integrieren.
9
Michael Durrant

Es gibt zwei große Nachteile, denen ich normalerweise begegne:

  1. Unfähigkeit, Ihre gespeicherten Prozeduren zu testen. Sicher, es gibt einige Unit-Test-Frameworks, aber normalerweise treten Probleme auf, wenn mehrere Tests gleichzeitig ausgeführt werden (Parallelitäts- und Transaktionsprobleme).
  2. Die meisten Unternehmen möchten sich viel in gespeicherte Prozesse einloggen, stellen dann aber 5x mehr Anwendungsprogrammierer (sei es C #, Ruby, Java usw.) als Datenbankprogrammierer oder Datenbankadministratoren ein und erwarten aus irgendeinem Grund, dass alle ihre App-Codierer dies tun sollten vollständig verstehen und in der Lage sein, performante, skalierbare Datenbankprozeduren (in PL/SQL, T-SQL oder was auch immer) zu schreiben. Das Management merkt normalerweise nicht, dass dies mit der Einstellung eines C # -Experten vergleichbar ist, der Ihnen etwas Python Code) schreibt, und sich fragt, warum sie keine erstaunlichen Anwendungen schreiben.
7
rally25rs

Es hängt davon ab, ob

Es hängt alles von Ihrem team's experience und dein project's requirements. Bringen Sie einen DBA in Ihr Team und entscheiden Sie, was Sie tun sollen, um die Anforderungen zu erfüllen. Bei einem mehrschichtigen Anwendungsdesign ist es jedoch möglicherweise nicht die gute Entscheidung, Geschäftslogik in gespeicherte Prozeduren zu kapseln.

Es wird nichts ausmachen

Solange Geschäftslogik:

  • lebt an einem Ort
  • wo es richtig dokumentiert ist
  • der ordnungsgemäße Zugriff erfolgt über Dienste, die lose gekoppelt werden können
  • über eine veröffentlichte abstrahierte Schnittstelle

Ich denke, dass business logic in programming space makes more sense wann Power of Expression ist wichtig in Ihrem Team/Projekt.

Ich glaube, dass SQL Space nicht so ausdrucksstark ist, aber it can do the job. Verwenden Sie die besten Werkzeuge, die Sie für die am besten geeigneten Aufgaben zur Verfügung haben. Das Spielen mit Logik und Konzepten höherer Ordnung ist am besten am highest level. Folglich Speicher- und Massendatenmanipulation erfolgt am besten auf Serverebene, wahrscheinlich in gespeicherten Prozeduren.

6
Yusubov

In der Moderne ist dies kein gängiger Ansatz mehr. Es gab eine Zeit, in der das Einfügen von Geschäftslogik in gespeicherte Prozeduren zu Beginn der Webprogrammierung üblich war, da die Alternativen nur wenige und oft schwierig zu verwenden waren. Heute würde ich dagegen empfehlen.

Ich muss sagen, dass es 2012 nichts über Geschäftslogik in gespeicherten Prozeduren gibt, was als eine Wahl gerechtfertigt sein könnte, die andere Ansätze übertroffen hat, nachdem sie die Vor- und Nachteile abgewogen hat. Alle PRO-Punkte wären bestenfalls akademisch.

CON's Es ist kein Linq-Code. Die Zukunft von TSQL ist linq kompiliert, auch meine fangen an, es zu lernen.

Kompilierter Code ist stabiler und einfacher zu bearbeiten. Wenn ich etwas debugge, sind so viele Informationen verfügbar, wenn ich C # oder Java verwendet habe.

Gespeicherte Prozeduren haben wahrscheinlich zu viele Verantwortlichkeiten. Es wird empfohlen, Ihre Verantwortlichkeiten auf 1 zu beschränken.

Mangelnde Aufgabentrennung führt zu einer Anwendung, die immer schwieriger zu bearbeiten und immer weniger stabil ist, da ihre Kernklassen immer größer werden.

Wenn Sie Microsoft Asp.Net MVC in Kombination mit Entity Framework Code First mögen, können Sie schnell Anwendungen erstellen und benötigen keine gespeicherten Prozeduren.

3
Honorable Chow