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

Die meisten Softwareentwickler möchten die Anwendungslogik in der Anwendungsschicht belassen, und es ist für uns wahrscheinlich eine Selbstverständlichkeit, sie hier beizubehalten. Datenbankentwickler scheinen Anwendungslogik als Trigger und gespeicherte Prozeduren in die Datenbankebene integrieren zu wollen.

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

Was halten Sie davon und was sollte oder sollte nicht in der Datenbankebene implementiert werden können?

Bearbeiten Diese Frage wird aus DBAs- Sicht auch in dba.se behandelt . Da programmers.se und dba.se unterschiedliche Zielgruppen und Vorurteile haben, möchten zukünftige Leser möglicherweise beide Antworten überprüfen, bevor sie entscheiden, was für sie am besten geeignet ist.

Die Vorteile , Logik in die Anwendungsebene zu integrieren.

1. Testbarkeit . Dies sollte eigentlich ein guter Grund für sich sein.
2. Bessere Codestruktur . Es ist sehr schwierig, die richtige OO-Architektur mit SQL zu verfolgen. Dies erleichtert in der Regel auch die Pflege des Codes.
3. Einfacher zu codieren . Aufgrund all der verschiedenen Sprachfunktionen, die in der von Ihnen verwendeten Sprache verfügbar sind, ist es in der Regel einfacher, in der Anwendungsebene zu programmieren.
4. Wiederverwendung von Code . Es ist viel einfacher, Code für Bibliotheken freizugeben, als Code in der Datenbank freizugeben.

Es ist zwar möglich, die Versionskontrolle mit gespeicherten Prozeduren zu verwenden (zum Beispiel, wenn die Redgate-Datenbanktools in TFS integriert sind), dies ist jedoch nicht immer so einfach wie mit Anwendungscode.

Meine Standardeinstellung ist, dass die Logik nicht in die Datenbankebene eingebunden werden soll. Manchmal ist es jedoch effizienter, die Logik in der Datenbank zu implementieren. In diesem Fall müssen Sie sicherstellen, dass Sie Änderungen an diesem Code nachverfolgen können.

In einer Firma, in der ich gearbeitet habe, gab es eine Menge Bürokratie, die mit der Freigabe von Code für die Produktion verbunden war, und die Einbindung eines DBAs für eine Code-Freigabe war immer ein Albtraum. Wir haben immer die Logik in die Anwendungsebene gelegt, um zu vermeiden, dass wir uns mit schwer zu bearbeitenden DBAs befassen müssen. Es ist ein total lahmer Grund, aber einer, der aus der Not heraus entstanden ist.

Das Einfügen von Anwendungslogik in die Datenbank klingt für mich nach einer schlechten Idee. Eine OTOH-Putting-Logik in der DB, die speziell Teil der Aufrechterhaltung des DB-Status ist (z. B. Trigger / Sprocs zum Aktualisieren von de-normalisierten Tabellen), ist ein ganz anderer Vorschlag.

Alternativ kann dies wie folgt ausgedrückt werden: Es gibt gute Argumente, um die Logik, die erforderlich ist, um zu abstrahieren, wie die Datenbank tatsächlich funktioniert, von der Art und Weise zu unterscheiden, wie sie in die Datenbank eingesehen werden soll.

Nachdem wir beide Fragen gelesen haben, haben wir wahrscheinlich alle einen kritischen Punkt übersehen. Die richtige Antwort hängt möglicherweise von der Art der von Ihnen entwickelten Software ab. Die DBA-Gruppe arbeitet zum größten Teil an unternehmenskritischen Unternehmenssoftwaresystemen, und ihre Antworten geben in der Regel das wieder, was in dieser Welt erforderlich ist. Es gibt einen großen Unterschied, was für diese Art von Anwendungen benötigt wird, als was für die nächste "Facebook" -Anwendung benötigt wird. Es ist keine große Sache, wenn Sie ein paar Pinnwandposts verlieren, es ist, wenn Sie ein paar Bestellungen oder andere finanzielle Transaktionen verlieren.

Die Leute, die in der COTS-Welt (Commercial Off-the-Shelf) arbeiten, müssen aus Vertriebsgründen datenbankunabhängig sein, und sie möchten, dass alles in konformem Code die Rückentwicklung erschwert und ihr Produkt durch ein selbst entwickeltes Produkt ersetzt. Die unternehmenseigenen Anwendungen, die entwickelt und gewartet werden, müssen fast nie die Datenbank-Backends ändern, außer für ein Upgrade.

Unternehmensanwendungen sind auch diejenigen, die dazu neigen, Eingaben von vielen Stellen zu erhalten, wobei die Datenbank die einzige Gemeinsamkeit darstellt. Das System, in dem ich arbeite, verfügt über Hunderte von verschiedenen Anwendungen, die darauf zugreifen, sowie über Hunderte von Importen von Kundendaten, Exporten von Daten an Kunden und an Data Warehouses und verwendet mehrere Berichtssysteme. Der Code, der beim Hinzufügen eines Datensatzes gut funktioniert, schlägt fehl, wenn ich 20.000.000 importieren muss. Wir mussten die Anwendungsebene einmal verwenden, da sich dort die Logik befand und wir den Vorgang 18 Stunden später unvollendet beenden mussten. Die Logik, die für alle Datensätze in einer Tabelle gelten soll, muss sich in der Datenbank befinden, wenn Sie nicht über eine Datenschicht verfügen können, die jeder verwendet.

Umgekehrt sind die Regeln unterschiedlich, wenn nur eine Anwendung die Daten verbraucht und die Daten nicht das Lebenselixier Ihres Unternehmens sind oder von höchster Bedeutung sind, und es ist sinnvoller, die gesamte Logik in die Anwendung aufzunehmen.

Länglich. siehe Zusammenfassung unten.

RDBMS

Ein RDBMS steht für relationales Datenbankmanagementsystem. Es ist ein System zur Verwaltung einer relationalen Datenbank. Dort werden die Daten gespeichert. Die Daten. Es heißt nicht Geschäftslogik.

Geschäftsprozess

Was bedeutet eigentlich Geschäftslogik? Für mich ist es die logische Beschreibung von Geschäftsprozessen.

Prozesse sind jene Geschäftsaktivitäten, die regelmäßig stattfinden, so dass sie nicht mehr ad hoc sind. Diese sind für jedes Unternehmen unterschiedlich.

Lassen Sie mich meine Geschäftsbeschränkung aufsetzen und erklären, was Geschäft hier bedeutet. Für manche mag dies eine Überraschung sein.

Geschäft

Geschäft ist die Summe der Aktivitäten, die zur Wertschöpfung durchgeführt werden, insbesondere der Wert, der gehandelt werden kann. Dies kann bedeuten, dass Mähdrescher, Thunfischsandwiches oder Bankdienstleistungen erbracht werden. In den meisten Ländern der Welt, auch in nichtkapitalistischen Systemen, möchten die Menschen den höchsten Gegenwert für ihr Geld erzielen, und daher gibt es einen Wettbewerb zwischen verschiedenen Anbietern dieser geschätzten Waren und Dienstleistungen. Der Wettbewerb hängt im Allgemeinen von Preis, Qualität und Verfügbarkeit ab.

Schneller Umweg: Sie benötigen 40 Millionen Nieten in 2 Tagen. Sie werden nicht bei einem Mann im Internet mit einem Paypal-Konto bestellen, egal wie viel billiger sein Preis ist als der Ihres normalen Verkäufers.

Prozesswissen

Wie Sie sich vorstellen können, leben die Prozesse, die zur Schaffung dieses "Wertes" erforderlich sind, hauptsächlich in den Führungskräften. Ein Teil davon wird auf Papier gebracht und als Unternehmensrichtlinien und -verfahren verwendet. Ein Teil davon lebt in den Leitern der Unternehmensberatung. Vieles davon lebt im Kopf der Leute, die die Abteilungen, Abteilungen, Teams und die Maschinen, die Registrierkassen, die Öfen und die Lastwagen leiten. Eine kleine Teilmenge davon reduziert die geschäftlichen Anforderungen an Software, und eine noch kleinere Teilmenge davon ist genau, wenn sie in Computersystemen implementiert wird.

Letztendlich ist die Geschäftslogik, die Sie im Code sehen, nicht diejenige, die ein Geschäft betreibt, sondern diejenige, die die Anwendung für das Geschäft betreibt. Die tatsächlichen Gehirne in den tatsächlichen Menschen enthalten die tatsächlichen Geschäftsprozesse, und sie haben kein Problem damit, zu verstehen, dass der Prozess in ihrem Gehirn genauer ist als der Prozess im Computer. Abgesehen davon könnten Sie das Geschäft wahrscheinlich nicht führen, wenn Sie nur die Richtlinien und Verfahren der meisten Unternehmen hätten. Sehr oft sind diese grob ungenau, trotz herkulischer Bemühungen.

Letztendlich ist es also die Anwendungslogik, die in der Software codiert ist. Und die Leute wollen das in die Datenbank aufnehmen, weil die Anbieter von Datenbankverwaltungssystemen grandiose Ansprüche erhoben haben.

Anwendungslogik

Ich sage nein. Ich sage Anwendungslogik bleibt in der Anwendung. Die Daten werden auf eine sehr normalisierte Weise in der Datenbank abgelegt und dann per ETL an das Data Warehouse weitergeleitet, um Berichte zu erstellen, zu bohren und zu rollen sowie zu drehen und zu würfeln.

Daten

Ich sage auch, dass die Daten die Anwendung überleben, sodass der Aufwand für die Datennormalisierung nicht anwendungsspezifisch und nicht einmal geschäftsspezifisch sein sollte, sondern allgemeiner Natur sein sollte. Speichern Sie staatliche Codes? Sie sollten INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) verwenden, da dies unternehmensweit übertragbar ist. Dies erleichtert auch mehreren Anwendungen das Manipulieren der Daten.

NoSQL?

Wenn Sie die Datenbank als Teil des Codes der Anwendung behandeln, vom Tabellenlayout bis zu den Triggern, gespeicherten Prozeduren und Datenformaten, verwenden Sie die Unternehmensdatenbank im Wesentlichen als verherrlichte BerkleyDB, eine verherrlichte flache Dateistruktur. Das ist wirklich nur persistierte Listen. Dies ist im Wesentlichen das, was NoSQL tut: Zurück zu den Wurzeln, aber dies in einer Multiprozess-beständigen und fehlertoleranten Weise.

Tatsächlicher Code

Nein, Sie müssen die Datenbank als ein gemeinsames Datenrepository für mehrere aktuelle und zukünftige Anwendungen behandeln. Jetzt kommen wir zum Kern meiner Argumentation. Geschäftsprozesse ändern sich mit den Launen des Marktes, der Politik und der Mode. Sehr oft ändern sie sich schneller als das, was Programmierer mit Sprachen für Computerwissenschaften (Java, C #, C ++ usw.) können, und werden in der Buchhaltungs- oder Marketingabteilung in Excel-Tabellen in VBA geschrieben. (Und nur wenn es nicht in ausgefallenen Lookups ausgedrückt werden kann ...)

Verschlechterung der Datenbank

Die Daten ändern sich nicht viel, wenn sie gut organisiert sind. Die Geschäftslogik ändert sich sehr schnell. Durch das Einfügen von Geschäftslogik in die Datenbank wird die Datenbank weniger wertvoll, da sie früher veraltet und ungenau wird.

Zusammenfassung

Daten müssen die Anwendung überleben, da Geschäftsprozesse in der Anwendung ablaufen und sich Geschäftsprozesse viel häufiger ändern. Das Einbeziehen von Geschäftslogik in die Datenbank ist schlecht für die Langlebigkeit und den Gesamtwert.

Vorbehalt

Ich habe meinen Teil von dba-ing getan und die Antworten auf dba.se gelesen, aber ehrlich gesagt geht es um Datenintegritäts- und Leistungsprobleme. Ich stimme voll und ganz zu, dass Personen, die Unternehmensdaten berühren, wissen sollten, was sie tun, ob DBA oder Programmierer oder SAS-Senior-Analyst mit Lese- / Schreibzugriff.

Ich bemerkte auch, dass sie Codierer empfehlen, SQL zu kennen. Genau. Es ist eine Computerprogrammiersprache, daher verstehe ich nicht, warum Computerprogrammierer es nicht wissen wollen.

Später, nachdem ich darüber nachgedacht habe

Ich denke, der Mittelweg besteht darin, eine API zu erstellen und diese API den Datenfluss hin und her verwalten zu lassen. Wenn Sie nicht zulassen können, dass Apps eine direkte Verbindung zu Tabellen herstellen, können Sie den Zugriffsmechanismus zumindest in modernen Sprachen einrichten.

Die Idee der Anwendungslogik in der Datenbank birgt die Gefahr dramatischer Klänge . Viele Antworten haben sich auf die Vorteile der Softwareentwicklung konzentriert. Der Kürze halber werde ich mich auf die Vorteile konzentrieren, die sich aus der Aufteilung der Verantwortung ergeben.

Datenbanken bieten eine effiziente Möglichkeit zum Speichern und Zugreifen auf Informationen, während redundante Daten minimiert und logische Beziehungen in den Daten hergestellt werden. Obwohl die Datenbanklogik möglicherweise in der Lage ist, Geschäftslogik auf Produktionsebene zu implementieren, sollte die Datenbank meiner Meinung nach so anwendungsunabhängig wie möglich sein, um sicherzustellen, dass die Daten von mehreren Anwendungen effektiv genutzt werden können, während die jeweiligen Stärken der Datenbank genutzt werden Engine im Vergleich zu den Stärken der Implementierungssprache der Anwendung.

Ein Benutzer der DBA-Stapelbörse gab an, dass ...

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.

Die letzten Fortune 500, bei denen ich gearbeitet habe, hatten Anwendungen, die in mindestens 25 Sprachen geschrieben waren und deren OLTP-Datenbank erreichten. Einige dieser Programme gingen in den 1970er Jahren in Produktion.

... gefolgt von seiner Überzeugung, dass dies auf eine Verletzung des DRY-Prinzips hindeutet.

Anstatt eine Wiederholung der Geschäftslogik zu sein, ist dies meines Erachtens eher ein perfektes Beispiel für die Flexibilität, die durch eine eindeutige Aufteilung der Zuständigkeiten zwischen der Geschäftsschicht und der Datenschicht gegeben ist.

Die OLTB-Datenbank liefert seit Jahrzehnten zuverlässig und effizient Daten für mehr als 25 Anwendungen! Das ist erstaunlich! (Weiter so!)

Ich kann nur davon ausgehen, dass die Daten nicht für bestimmte Anwendungen geeignet sind. Etwas, das größtenteils unmöglich wäre, wenn diese Entwickler versuchen würden, mithilfe der Datenbanklogik etwas zusammen zu hacken.

Wie andere Antworten gezeigt haben, gibt es viele andere Gründe, ein Programm nicht in der Datenbank zu implementieren. Ich bin sicher, es würde funktionieren, aber das wahrscheinlichste Ergebnis wäre jahrzehntelanges Bedauern und nicht jahrzehntelange Stabilität.

Für datenbankunabhängige Anwendungen ist die gesamte Logik der Datenbanken erforderlich. Es ist sehr schwierig, Code für viele verschiedene Datenbankanbieter zu erstellen und zu verwalten.

Eine gute Entwicklung wird ein gutes Gleichgewicht zwischen dem Erfordernis der Datenbankintegrität und der Geschwindigkeit herstellen, indem ein Teil der Logik in die Datenbank und der größte Teil in die Anwendung eingefügt wird.

Wird dieselbe Abfrage in vielen Anwendungen immer wieder verwendet, gehört sie möglicherweise zu einer gespeicherten Prozedur.

Es liegt in der Verantwortung des DBA, dafür zu sorgen, dass beim Einfügen und Aktualisieren einer Zeile die Felder für die Haushaltsführung festgelegt werden. Ein Auslöser wird verwendet.

Wenn ich hingegen über Geschäftslogik verfüge, muss diese in der Anwendung vorhanden sein. Es sollte nach Möglichkeit Aufrufe an gespeicherte Prozeduren vornehmen, die den gewünschten, gefilterten Datensatz mit der genauen Anzahl der benötigten Felder zurückgeben. Nicht mehr und nicht weniger.

Es geht um die Kommunikation zwischen den Teams und darum, die Vor- und Nachteile der einzelnen Möglichkeiten zu erkennen.

Meine Meinung ist: Machen Sie die Anwendungslogik in DB nicht zu tief.

Einige Handelssysteme bieten die Möglichkeit, die vorhandene Funktionalität mit Skripten zu erweitern, die im Grunde genommen in die Datenbank gestellt werden. Meine Erfahrung damit ist eher negativ, zumindest in einer Multi-User-Einstellung.

Sie würden Logik in eine Datenbank einfügen, weil Sie diese Logik einfach ändern möchten.

• Wie würden Sie die Versionskontrolle durchführen?
  • Was ist der Code-Verlauf? Was hat sich geändert? Von wem?
  • Wie könnten Sie mit Änderungen an denselben Codefragmenten umgehen?
• Wie würden Sie einen konsistenten Codezustand identifizieren und garantieren?

Sie könnten dies in einem zusätzlichen dateibasierten VCS nachverfolgen, aber was ist dann der Vorteil der Datenbank?

Die meisten Anwendungen müssen eine Möglichkeit zur Integration bieten. Idealerweise verfügen Sie über eine vollständige API, einen Webdienst oder stellen zumindest einige Datenbankobjekte mit Geschäftslogik zur Verfügung. Da nicht jeder in der Lage ist, eine API zu erstellen, müssen Sie Kompromisse eingehen.