Geschäftslogik: Datenbank oder Anwendungsebene

Wartbarkeit des Codes ist immer ein großes Problem bei der Bestimmung, wo die business-Logik sollte das gehen.

Integrierten debugging-tools und mehr leistungsfähige IDEs im Allgemeinen, die Aufrechterhaltung der middle-tier-code einfacher, als den gleichen code in eine gespeicherte Prozedur. Es sei denn, es ist ein echter Grund sonst, sollte man beginnen mit der Geschäftslogik der mittleren Schicht/Anwendung und nicht in gespeicherten Prozeduren.

Aber wenn Sie kommen, um reporting-und data-mining, Suche, gespeicherte Prozeduren können oft die bessere Wahl. Dies ist Dank der Leistung der Datenbanken aggregation/Filter-Funktionen und die Tatsache, dass Sie halten Sie die Verarbeitung ganz in der Nähe der Quelle der Daten. Aber das kann nicht sein, was die meisten betrachten klassische business-Logik sowieso.

InformationsquelleAutor der Antwort Ash

Es ist wirklich bis zu Sie, solange Sie konsistent.

Einen guten Grund, um es in Ihr Datenbank-layer: wenn Sie sind ziemlich sicher, dass Ihre Kunden nie ändern Sie Ihre Datenbank-back-end.

Einen guten Grund, um es in den application-layer: wenn Sie auf mehrere Persistenz-Technologien für Ihre Anwendung.

Sollten Sie auch berücksichtigen Kernkompetenzen. Sind Ihre Entwickler vor allem application-layer-Entwickler, oder sind Sie in Erster Linie der DBA-Typen?

InformationsquelleAutor der Antwort Jon Limjap

Zwar gibt es keine richtige Antwort - es hängt davon ab, das Projekt in Frage, würde ich empfehlen den Ansatz, wie er im "Domain-Driven Design" von Eric Evans. In diesem Ansatz wird der Geschäfts-Logik ist isoliert in seiner eigenen layer - der domain layer - die sitzt oben auf der Infrastruktur-Schicht(N) - die könnte auch Ihre Datenbank-code, und unterhalb der Anwendungsschicht, die die requests sendet in der domain-Ebene für die Erfüllung und wartet auf eine Bestätigung Ihrer Fertigstellung, effektiv fahren die Anwendung.

Diese Weise, die business-Logik ist eingefangen in ein Modell, das diskutiert werden kann, mit denen, die verstehen das Geschäft abgesehen von den technischen Fragen, und es macht es einfacher zu isolieren, die Veränderungen in der Wirtschaft Regeln selbst, die technischen Fragen der Umsetzung und der Ablauf der Anwendung und die Interaktion mit den Unternehmen (domain) - Modell.

Empfehle ich die Lektüre des oben genannten Buches, wenn Sie die chance bekommen, da es ziemlich gut zu erklären, wie das Reine ideal kann tatsächlich angenähert werden, in der realen Welt der realen code und Projekte.

InformationsquelleAutor der Antwort Foo42

Alles, was wirkt sich auf die Integrität der Daten gestellt werden kann, muss auf der Datenbank-Ebene. Andere Dinge neben der Benutzeroberfläche oft Daten in, aktualisieren oder löschen von Daten aus der Datenbank einschließlich der Einfuhren, Massen-updates zu ändern, ein Preismodell, hot-fixes, etc. Wenn Sie müssen sicherstellen, dass die Regeln immer befolgt werden, die Logik in Standardwerte und Trigger.

Dies ist nicht zu sagen, dass es nicht eine gute Idee, haben es auch in der Benutzeroberfläche (warum sich die Mühe machen, Informationen zu verschicken, dass die Datenbank nicht akzeptieren), aber zu ignorieren, diese Dinge in die Datenbank vor Gericht Katastrophe.

InformationsquelleAutor der Antwort HLGEM

Ist es heutzutage möglich, zu Unterwerfen subversion Ihre gespeicherte Prozedur code und zum Debuggen dieses Codes mit der guten tool-Unterstützung.

Wenn Sie gespeicherte Prozeduren kombinieren, dass sql-Anweisungen Sie können die Datenmenge reduzieren, den Datenverkehr zwischen der Anwendung und der Datenbank ein und reduzieren Sie die Anzahl der Datenbank-Aufrufe und gewinnen große performance-Gewinne.

Sobald wir begonnen, die Gebäude in C# haben wir die Entscheidung getroffen, nicht zu verwenden gespeicherte Prozeduren, aber jetzt bewegen wir uns mehr und mehr code für gespeicherte Prozeduren. Vor allem die batch-Verarbeitung.

Jedoch nicht verwenden, Trigger, gespeicherte Prozeduren oder besser Pakete. Löst sich verringern die Wartbarkeit.

InformationsquelleAutor der Antwort tuinstoel

Die einzige Sache, die geht in eine Datenbank Daten.

Gespeicherte Prozeduren sind ein Wartungs-Albtraum. Sie sind nicht Daten, und Sie gehören nicht in der Datenbank. Die endlosen Koordination zwischen Entwicklern und DBA ' s ist wenig mehr als organisatorische Reibung.

Es ist schwer zu halten, die gute version, die Kontrolle über gespeicherte Prozeduren. Der code außerhalb der Datenbank ist wirklich einfach zu installieren -- wenn du glaubst, du hast die falsche version, die Sie gerade tun, ein SVN UP (vielleicht ein install) und Ihre Anwendung zurücksetzen auf einen bekannten Zustand. Sie haben Umwelt-Variablen, Verzeichnis, links, und viele Umgebung die Kontrolle über die Anwendung.

Können Sie, mit einfachen PATH Manipulationen, haben Variante der software zur Verfügung, die für verschiedene Situationen (training, test, QA, Produktion, Kunden-spezifische Erweiterungen, uvm., etc.)

Den code in der Datenbank, jedoch viel schwieriger zu verwalten. Es gibt keine saubere Umgebung-kein "PFAD", links directory oder andere Umgebungsvariablen -- zu leisten, die nutzbare Kontrolle darüber, welche software verwendet wird; Sie haben eine dauerhafte, Global gebundene Sammlung von Anwendungs-software bleiben in der Datenbank, verheiratet auf die Daten.

Trigger sind noch schlimmer. Sie sind beide eine Wartung und ein debugging-Alptraum. Ich sehe nicht, welches problem Sie lösen; Sie scheinen ein Weg zu sein, zu arbeiten, um schlecht konzipierte Anwendungen, wo jemand konnte nicht belästigt werden, mit den verfügbaren Klassen (oder Funktionsbibliotheken) richtig.

Während einige Leute finden, die das performance-argument überzeugend, ich habe noch nicht genug gesehen, um benchmark-Daten, um mich zu überzeugen, dass gespeicherte Prozeduren sind schnell. Jeder hat eine Anekdote, aber niemand hat side-by-side-code, in dem die algorithmen sind mehr oder weniger die gleichen.

[In den Beispielen, die ich gesehen habe, die alte Anwendung war eine schlecht gestaltete Durcheinander, wenn die gespeicherten Prozeduren geschrieben wurden, wurde die Anwendung re-architected. Ich denke, dass das design ändern, hatte mehr Einfluss als die Plattform ändern.]

InformationsquelleAutor der Antwort S.Lott

Die Antwort nach meiner Erfahrung liegt irgendwo auf einem Spektrum der Werte in der Regel bestimmt durch, wo Ihre Organisation Fähigkeiten liegen.

DBMS ist ein sehr mächtiges Tier, das heißt eine richtige oder unsachgemäße Behandlung großen nutzen bringen oder große Gefahr. Leider, in zu vielen Organisationen, primäre Augenmerk wird auf die Programmierung, Personal, dbms Kenntnisse, insbesondere Abfrage-Entwicklung Fähigkeiten (im Gegensatz zu administrative) vernachlässigt werden. Das wird durch die Tatsache verschärft, dass die Fähigkeit zu bewerten, dbms Kenntnisse wird wahrscheinlich auch fehlen.

Und es gibt nur wenige Programmierer, die ausreichend verstehen, was Sie nicht verstehen, über Datenbanken.

Damit die Popularität suboptimale Konzepte wie Active Records und LINQ (um zu werfen in einige offensichtliche Fehler). Aber Sie sind wahrscheinlich die beste Antwort für solche Organisationen.

Beachten Sie jedoch, dass hoch skaliert Organisationen neigen dazu, zahlen viel mehr Aufmerksamkeit auf die effektive Nutzung des datastore.

InformationsquelleAutor der Antwort dkretz

Business Logik wird in der Anwendungsebene und nicht in der Datenbank.
Der Grund dafür ist, dass eine Datenbank gespeicherte Prozedur ist immer dependen auf dem Datenbank-Produkt Sie verwenden. Diese Pause ein Vorteil des drei-Schichten-Modell. Sie können nicht einfach ändern, um eine andere Datenbank, es sei denn Sie bieten eine zusätzliche gespeicherte Prozedur für dieses Datenbank-Produkt.
auf der anderen Seite manchmal, macht es Sinn, die Logik in eine gespeicherte Prozedur für die Optimierung der performance.

Was ich sagen will ist, business-Logik ist in die Applikation tier, aber es gibt auch Ausnahmen (vor allem aus performance-Gründen)

InformationsquelleAutor der Antwort

Imho. es gibt zwei widersprüchliche Anliegen mit der Entscheidung, wo Sie business-Logik geht in einer relationalen Datenbank-gestützte app:

• Wartbarkeit
• Zuverlässigkeit

Re. Wartbarkeit: damit für eine efficient future development, business-Logik gehört in den Teil der Anwendung, die am einfachsten zu Debuggen und zu version control.

Re. Zuverlässigkeit: Wenn es erhebliche Gefahr der Inkonsistenz, business-Logik gehört in den Datenbank-layer. Relationale Datenbanken entworfen werden können, um zu überprüfen, für die Einschränkungen auf Daten, z.B. nicht erlaubt NULL-Werte in bestimmte Spalten, usw. Wenn ein Szenario entsteht, die in Ihrer Anwendung design, wo einige Daten müssen in einem bestimmten Zustand, das ist zu Komplex, um Sie auszudrücken, mit diesen einfachen Einschränkungen, kann es Sinn machen, verwenden Sie einen trigger oder ähnliches in der Datenbank-Schicht.

Trigger sind ein Schmerz zu halten Sie up-to-date, vor allem, wenn Ihre app soll für die Ausführung auf client-Systeme, die Sie gar nicht haben Zugang zu. Aber das bedeutet nicht, dass es unmöglich ist, den überblick zu behalten oder zu aktualisieren. S. Lott, die die Argumente in seiner Antwort, dass es ist ein Schmerz und Streit sind völlig gültig ist, werde ich zweite, und wurden es auch. Aber wenn Sie halten diese Einschränkungen im Hinterkopf, wenn Sie den ersten Entwurf Ihrer Daten-Schicht und die Nutzung von Triggern und Funktionen, die für nichts, aber die absolute Notwendigkeiten, es ist überschaubar.

In unserer Anwendung, die meisten business-Logik enthalten ist, in der Anwendung Modell-Schicht, z.B. eine Rechnung, weiß, wie Sie initialisiert werden, sich von einem bestimmten Kundenauftrag. Wenn eine Reihe von verschiedenen Dinge, die geändert werden der Reihe nach für eine komplexe Reihe von änderungen wie diese, wir Rollen Sie in einer Transaktion die Konsistenz zu wahren, statt sich für eine gespeicherte Prozedur. Berechnung von Summen etc. sind alle fertig mit Methoden der Modell-Ebene. Aber wenn wir es brauchen denormalize etwas zur Leistung oder einfügen von Daten in einen 'änderungen' Tabelle für alle Kunden, um herauszufinden, die Objekte, die Sie benötigen, zu verfallen, in Ihre session cache verwenden wir Trigger/Funktionen in der Datenbank-Schicht, um eine neue Zeile einfügen und senden eine Benachrichtigung (Postgres listen/notify Zeug) aus dieser trigger.

Nachdem unsere app in das Feld für über ein Jahr, von Hunderten von Kunden jeden Tag, das einzige was ich ändern würde, wenn wir von vorne anfangen, wäre die design-unser system für die Erstellung von Datenbank-Funktionen (oder Prozeduren gespeichert, aber Sie wollen, Sie zu nennen) mit Versionierung und updates, um Sie in den Geist von der get-go.

Glücklicherweise haben wir ein system im Ort zu halten Spur von schema-Versionen, also Bauten wir etwas auf, um die Pflege zu ersetzen, Datenbank-Funktionen. Es würde gespeichert haben uns ein paar mal nun, wenn wir die würde als die Notwendigkeit, Sie zu ersetzen, die aus der Anfang obwohl.

Natürlich, alles ändert sich, wenn Sie Schritt außerhalb des Bereichs von RDBMS ist in Tupel-storage-Systeme wie die von Amazon SimpleDB und Googles BigTable. Aber das ist eine andere Geschichte 🙂

InformationsquelleAutor der Antwort Dirk Stoop

Skalierbarkeit ist auch ein sehr wichtiger Faktor für pusing Geschäftslogik in der mittleren oder in der app-Schicht als auf Datenbank-Ebene.Es sollte verstanden werden, dass DatabaseLayer ist nur für die Interaktion mit der Datenbank nicht manipulieren, der zurückgegeben wird, oder aus der Datenbank.

InformationsquelleAutor der Antwort

Es ist ein Kontinuum. IMHO der größte Faktor ist die Geschwindigkeit. Wie kann u bekommen diese Trottel so schnell wie möglich, während immer noch die Einhaltung der guten Mietern der Programmierung wie Wartbarkeit, performance, Skalierbarkeit, Sicherheit, Zuverlässigkeit usw. Oft SQL ist die prägnanteste Art und Weise, etwas auszudrücken, was auch geschieht, werden die meisten performant, viele Male, außer bei string-Operationen etc, aber das ist, wo Ihre CLR-Prozeduren helfen können. Meine überzeugung ist großzügig bestreuen business-Logik um, egal wo Sie fühlen, am besten ist es für die Unternehmen auf der hand. Wenn Sie eine Gruppe von Anwendungs-Entwickler, die die Scheiße Ihrer Hose, wenn man sich an SQL-dann lassen Sie Sie nutzen Ihre app-Logik. Wenn Sie wirklich wollen, zu schaffen eine hohe Leistung Anwendungen mit großen Datenmengen, so viel Logik in der DB, wie Sie können. Feuer Ihre DBA ' s und Entwickler die ultimative Freiheit, über Ihre Dev-Datenbanken. Es gibt keine eine Antwort oder beste Werkzeug für den job. Sie haben mehrere tools, die so zu Experten auf allen Ebenen der Anwendung und Sie werden bald feststellen, dass Sie verbringen viel mehr Zeit mit dem schreiben schön consise expressive SQL-soweit angezeigt und mit der Anwendungsschicht zu anderen Zeiten. Zu mir, letztlich reduzieren die Anzahl der Codezeilen ist, was führt zu Einfachheit. Wir haben gerade umgebaut eine sql-reiche Anwendung mit nur 2500 Zeilen von app-code und 1000 Zeilen SQL, um ein domänenmodell, das hat jetzt 15500 Zeilen von app-code und 2500 Zeilen SQL zu erreichen, was der ehemalige sql-rich-app haben. Wenn Sie können, rechtfertigen eine 6-fache Steigerung im code als "vereinfacht" dann gehen Sie nach rechts weiter.

InformationsquelleAutor der Antwort bobthecoder

Dies ist eine große Frage! Ich fand das, nachdem ich bereits gebeten, ein simliar Frage, aber das ist mehr spezifischen. Es kam als Ergebnis eines design-Entscheidung zur Veränderung, dass ich war nicht daran beteiligt.

Im Grunde, was mir gesagt wurde war, dass Wenn Sie Millionen von Zeilen von Daten in Ihre Datenbank-Tabellen suchen, dann schauen Sie bei der Inbetriebnahme, business Logik in stored procedures und Triggern. Das ist das, was wir gerade jetzt tun, die Konvertierung einer java-app in gespeicherten Prozeduren für die Wartbarkeit als die java-code hatte sich verwickelt.

Ich fand diesen Artikel auf: Die Business-Logik Wars Der Autor auch die Millionen Zeilen in einer Tabelle-argument, das ich interessant fand. Er hat auch Hinzugefügt, business-Logik in javascript ist client-Seite und außerhalb der business-Logik-Schicht. Ich hatte nicht darüber nachgedacht, bevor, obwohl ich schon verwendet javascript zur Validierung für die Jahre, zusammen mit server-seitige Validierung.

Meine Meinung ist, dass Sie wollen, dass die business-Logik in die Anwendung/middle tier-als Faustregel gilt, aber nicht Rabatt die Fälle, wo es Sinn macht, um es in die Datenbank.

Einen letzten Punkt, es gibt eine andere Gruppe, wo ich arbeite derzeit, das tut riesige Datenbank arbeiten für die Forschung und die Menge der Daten, die Sie beschäftigen, ist immens. Noch, für Sie und Sie haben keine business-Logik in die Datenbank selbst, aber halten Sie es in der Anwendung/middle tier. Für Ihr design, die Anwendung/middle tier war der richtige Platz für Sie, so würde ich nicht verwenden, die Größe von Tabellen als nur design berücksichtigt.

InformationsquelleAutor der Antwort James Drinkard