it-swarm.com.de

Geschäftslogik: Datenbank vs Code

Ich bin ein Student der Systemtechnik und alle meine Lehrer und Freunde (die tatsächlich in der Region arbeiten) sagen, dass es besser ist, so viel Logik wie möglich in der Datenbank zu implementieren (Abfragen, Ansichten, Trigger, ) T-SQL usw.). Ich denke, dass es besser ist, es im Code zu haben.

Ihre Gründe sind:

  • Wenn sie die Sprache ändern müssen, befindet sich fast die gesamte Logik in der Datenbank. Daher ist die Implementierungszeit minimal.

  • Änderungen in der Sprache sind häufiger als in der Datenbank.

Meine Gründe sind:

  • Es ist offensichtlich (zumindest im gegenwärtigen Umfeld meines Landes), dass sie die Sprache der Projekte nicht so leicht ändern. (Ich habe Programme gesehen, die sich noch in FoxPro befinden, denn wenn es funktioniert, muss es nicht geändert werden.).

  • In Programmiersprachen geht es um Funktionalität, in Datenbanken um Daten. Sie können Programmierfunktionen in Datenbanken haben, aber ich denke, dass diese auf die Komponenten beschränkt sein sollten, die sich auf Daten auswirken.

  • Es ist einfacher, neue Anforderungen zu implementieren (zum Beispiel: Wenn der Kunde eine API wünscht).

  • Wenn sie Logik in der Datenbank verwenden, ist der Rest der Logik, die im Code implementiert ist, normalerweise eher spaghettiartig (z. B. Zufallsfunktionen).

  • Im Allgemeinen ist es üblicher, mehr Programmierer als Datenbankadministratoren (DBAs) zu haben.

    Welche Implementierung ist die beste?

48
Larizza Tueros

Siehe Wie viel Geschäftslogik sollte die Datenbank implementieren? für die vorherige Diskussion.

Im Allgemeinen möchte jeder, dass die Dinge in der Ebene erledigt werden, die er kontrolliert. Weil sie es dann kontrollieren.

Jeder Datenbankanbieter möchte, dass die Benutzer so viel Logik wie möglich in die Datenbank einfügen. Weil das Sie in die Datenbank einschließt. Der Grund dafür ist, dass mehrere Anwendungen, die dieselbe Datenbank verwenden, Code wiederverwenden.

Programmierer sind jedoch nachdrücklich anderer Meinung. Datenbanken bieten schlechte Programmieroptionen. Das Bereitstellen von Code in Datenbanken ist schwierig. In Datenbanken fehlen grundlegende Tools für die Revisionskontrolle, die interaktive Bearbeitung, die Bereitstellung und das Testen von Einheiten. Gespeicherte Prozeduren beinhalten in der Regel schreckliche Debug-Aktionen aus der Ferne. Es ist seltener geworden, dass mehrere Anwendungen auf dieselbe Datenbank zugreifen. Und wenn Sie jemals etwas skalieren müssen, ist Ihre Datenbank der einzige Engpass, der am schwierigsten zu beheben ist.

Meine Voreingenommenheit ist klar. Ich bin Programmierer.

Aber ich programmiere seit fast 20 Jahren, hauptsächlich als Backend-Programmierer, der für Daten verantwortlich ist. Ich habe das Argument für das Verschieben von Logik in die Datenbank oft gesehen. Ich habe Systeme gesehen, die es getan haben, und Systeme, die es vermieden haben. Ich musste Datenbanken, Codebasen usw. usw. usw. migrieren.

Die schlimmsten Probleme gab es immer, wenn sich Geschäftslogik in der Datenbank befand. Sie waren immer am schwierigsten zu reparieren. Und ich kann sagen, dass ich, obwohl ich oft auf die Behauptung gestoßen bin, dass "wir die Logik für die Leistung in die Datenbank verschoben haben", mit einem sauberen normalisierten Datenmodell, guten Indizes und einer Caching-Schicht vor der Datenbank fast immer besser ist. und vernünftige Algorithmen, die in einer modernen Programmiersprache implementiert sind.

68
btilly

Ich bin der festen Überzeugung, dass wann immer möglich Geschäftslogik in der Softwareschicht und nicht in der Datenbankebene beibehalten werden sollte. Beachten Sie, dass wenn immer möglich weit hinter immer zurückbleibt.

Es gibt starke Argumente für beide Wege, und wie immer sollten Sie mit gutem Urteilsvermögen für jedes Projekt entscheiden, wie viel Gewicht auf jeden Punkt angewendet werden soll, bevor Sie entscheiden, welche die geeignetere Wahl ist.

( Wenn andere Personen in den Kommentaren Vorschläge machen, können sie der Liste hinzugefügt werden )

Argumente für die Datenbank, die Geschäftslogik behandelt :

  • Geschäftslogik benötigt Daten, um damit arbeiten zu können. Wenn die Logikverarbeitung so nah wie möglich an den Daten liegt, wird die Leistung verbessert
  • Ein Ort, um Updates anzuwenden

Argumente für die Softwareschichten, die mit Geschäftslogik umgehen :

  • Gut geschriebene Software ist in der Regel viel einfacher zu verstehen, zu debuggen und zu warten als gespeicherte SQL-Prozeduren.
  • Anwendungsserver können sowohl skaliert als auch skaliert werden, wenn die Internetanwendung populär wird.

Als erfahrener professioneller Entwickler, der eine schnelle Lösung zur Verbesserung der Anwendungslatenz benötigt, kann die Wahl zwischen dem Verschieben einer langsam laufenden Geschäftslogik in eine gespeicherte Prozedur in der Datenbank und/oder zum Implementieren des langsamen Zwischenspeicherns bestehen Prozesse.

Es gibt jedoch ein ernstes Problem mit der datenbankbasierten Geschäftslogik. Wenn Ihre Anwendung massiv skaliert werden muss, bevorzugen Sie immer Systeme/Prozesse, die skaliert werden können (damit meine ich, dass Sie dem Verarbeitungspool weitere Server hinzufügen können). SQL-Datenbanken können nur skaliert werden (Sie müssen einen leistungsstärkeren Server finden, um Ihren vorhandenen zu ersetzen). Wenn Ihre Anwendung über eine große Datenbankgeschäftslogik verfügt, werden Sie dieses Problem früher erreichen.

16
Michael Shaw

In Ihren datenbankfreundlichen Argumenten fehlen zwei sehr wichtige Punkte:

  • Leistung : Datenbankcode wird mit direktem Zugriff auf die Daten ausgeführt, wodurch unnötige Übertragungen vermieden werden (sei es über das Abrufen von API- und Zuordnungsschemata auf demselben Computer oder über das Netzwerk für die Client/Server-Kommunikation)
  • Konsistenz : Da mehrere Anwendungen auf dieselbe Datenbank zugreifen/diese aktualisieren können, wird durch die zentrale Zusammenfassung von Konsistenz- und Geschäftsregeln sichergestellt, dass diese zuverlässig durchgesetzt werden.

Es fehlen jedoch auch einige sehr wichtige Punkte in Ihren Gegendatenbankargumenten:

  • Skalierbarkeit : Je mehr Sie in die Datenbank einfügen, desto mehr wird diese Komponente zu einem Engpass. Natürlich können Sie größere Server verwenden und CPUs hinzufügen, aber früher oder später stoßen Sie an die physischen Grenzen.

  • Lieferantenbindung : SQL ist sehr standardisiert, aber die Sprachen für Trigger und Prozeduren sind ziemlich diversifiziert und oft proprietär: T-SQL für Microsoft, PL/SQL für Oracle, jede Sprache für DB2. Durch die Entwicklung der Datenbank werden Sie an einen Anbieter gebunden, und Sie können nicht von der zunehmenden Konkurrenz profitieren oder auf neue Betriebsumgebungen migrieren.

  • Legacy-Architektur : Überzentralisierung von Daten und Verarbeitung auf riesigen Servern ... Bringt uns das nicht zurück in die Ära der Mainframes? Dies scheint heutzutage veraltet zu sein, wenn neue wichtige Architekturtrends auftauchen, die auf maximale Skalierbarkeit abzielen: flexible NoSQL Datenbanken von verschiedene Typen ideal geeignet für objektorientierte Entwicklung, Microservices = Jeder Mikroservice verfügt über eine eigene Datenbank und eine BigData-Architektur wie Lambda-Architekturen , bei der sich alle Verarbeitungspipelines außerhalb der Datenbank befinden.

  • veraltete Argumente : Die Zeit des fehleranfälligen redundanten Cobol-Codes, der über Anwendungen hinweg kopiert wurde, ist vorbei. Was gestern nur zuverlässig in einem RDBMS gekapselt werden konnte, kann sehr gut in moderne Softwarearchitekturen gekapselt werden, indem wartbare und wiederverwendbare objektorientierte Komponenten, Bibliotheken und Versionskontrollsysteme verwendet werden.

Zusammenfassen:

  • ja, es gibt gültige Argumente, um das Maximum an Logik auf die Datenbankseite zu bringen. Diese Argumente erfüllen jedoch nicht mehr die neuen Bedürfnisse und Einschränkungen der Internet-Skala, des technologischen Wandels und der Entstehung von BigData.
  • nein, ich glaube nicht, dass es einen universellen besten Ansatz gibt. Der am besten geeignete Ansatz wird von einem Softwarearchitekten von Fall zu Fall auf der Grundlage der konkreten Anforderungen und Bedürfnisse ausgewählt.
10
Christophe

Denken Sie neben all den Fakten, auf die bereits hingewiesen wurde, auch daran, dass die Geschäftslogik in Ihrem Code enthalten ist und die Datenbank sich letztendlich als billiger herausstellt.

Wenn Sie nach einem Entwickler für eine Anwendung suchen, die in PHP geschrieben ist und MySQL als Datenbank verwendet, sollte Ihre Geschäftslogik in der gespeichert sein Datenbank, ein einfacher PHP Programmierer ist nicht genug, und Sie müssen jemanden finden, der auch weiß, wie man gespeicherte Prozeduren schreibt, debuggt und optimiert. Plötzlich brauchen Sie einen Mann, der nicht nur eines weiß , PHP, aber zwei, PHP und MySQL-Programmierung.

Und denken Sie nicht einmal daran, auf eine leistungsstärkere Engine wie PostgreSQL umzusteigen. Dann müssen Sie auch einen Mitarbeiter einstellen, der alle gespeicherten Prozeduren in PL/SQL umwandelt.

Wenn Sie Geschäftslogik im Code haben, müssen Sie nur eine neue Abstraktionsschicht für PostgreSQL schreiben und die Abhängigkeiten in Ihrer Anwendung austauschen. Boom, Ihre Anwendung kennt PostgreSQL plötzlich.

3
Andy

Frühere Antworten geben gute Gründe an, warum es einfacher/besser ist, Logik in Anwendungscode als in eine Datenbank einzufügen. Eine Ausnahme, die ich hervorheben möchte, ist die Verwendung einer Big-Data-Datenbank/eines Tech-Stacks. In diesem Fall verschwinden viele der Nachteile:

  • Sie können Komponententests schreiben, da sich der tatsächlich geschriebene Code in der Datenbank befindet.
  • Sie können debuggen, wenn auch durch Unit-Tests.
  • Sie haben Versionskontrolle, da es Code ist.

Und die Vorteile der Logik in der Datenbank werden immer wichtiger:

  • Abhängig von der Menge der Daten, die verarbeitet werden, kann es unangemessen sein, Daten an Ihren Anwendungscode zu senden.
  • Skalierung - Ihr Code skaliert genauso wie die Datenbank - in vielen Fällen sind Leistung und Speicher in Bezug auf die Anzahl der Knoten (Maschinen) linear.
1
ytoledano

Gute Frage - das befürworte ich sehr regelmäßig im Büro.

Meiner Ansicht nach sollte der größte Teil der Logik im Code enthalten sein. Es ist immer sehr verlockend, eine Vielzahl von Sprachen zu verwenden, da jede ihre Stärken hat. Wenn Sie jedoch kein perfektes Entwicklungssetup haben (was sehr selten ist), sollten Sie sich lieber an eine Sprache halten.

Die Leute haben die Versionierung von Unit-Tests/Revisionskontrollen erwähnt, aber eine sehr wichtige Sache ist die Bereitstellung. Das Synchronisieren von Datenbankcodeänderungen mit Codeänderungen kann gefährlich sein.

Wenn Sie in einem großen Softwareentwicklungsunternehmen arbeiten, haben Sie vielleicht genug spezialisierte Leute, die beide Seiten kennen (Datenbankprogrammierung vs. Codierung), aber ansonsten ist es schwierig, Leute zu finden, die zwischen den beiden Welten jonglieren können (und vor allem, wer Machen Sie die richtigen Kompromisse, wenn Sie entscheiden möchten, welcher Teil der Logik in welcher Sprache vorliegen muss.

Persönlich finde ich SQL-Programmiersprachen sehr primitiv und die Entwicklungstools für sie noch schlimmer. Ich würde also moderne Programmiersprachen bevorzugen. Ein guter ORM kann die meisten Entwickler davon abhalten, etwas über die Datenbank zu wissen, und es lohnt sich, in ihn zu investieren. Die Leute erwähnten die Effizienz der serverseitigen Arbeit, und dies sollte nicht aufgegeben werden. Es gibt einige sehr nette Programmiermuster, die es ermöglichen, serverseitige Operationen unter Verwendung einer scheinbar clientseitigen API auszudrücken (z. B. IQueryable in C #).

In der Praxis verwende ich immer noch die ungeraden Ansichten oder gespeicherten Prozeduren, aber sie dienen normalerweise nur der Aggregation und enthalten keine Geschäftslogik. Dies ist sehr nützlich, da sie beispielsweise als Quellen für Excel-Pivottables verwendet werden können.

0
joelhoro