Wie viel Businesslogik gehört in die Datenbank?

Eine Frage, welche mich schon seit längerem Beschäftigt ist, wie viel Logik oder Businesslogik man in der Datenbank verwenden sollte. Viele Leute, die ich in letzter Zeit zu diesem Thema befragt habe, sind entweder unsicher oder haben sehr unterschiedliche Meinungen. Die einen sagen, dass man alles möglichst in die Datenbank auslagern sollte und andere schwören auf leichtgewichtige Datenbanken, sprich Datenbanken, die nur Struktur inklusive Beziehungen und Daten enthalten.

Als erstes werde ich nun versuchen, einige Vor- und Nachteile zu finden.

Vorteile Logik in der Datenbank

  • Wiederverwendbarkeit der Stored Procedures mit verschiedenen Clients, so lange die DB die gleiche bleibt
  • Performance bei komplexen Berechnungen / Abfragen
  • Unter Umständen erhöht sich die Sicherheit, da der Sourcecode die Datenbankstruktur nicht offenlegt (aber nur wenn man alles ausgelagert hat)
  • Man kann mit sehr wenig Code sehr viel erreichen im Vergleich zu Programmiersprachen ( Validierung, Sicherheit )

Nachteile Logik in der Datenbank

  • Wiederverwendbarkeit, wenn die DB ausgewechselt werden soll
  • Als Programmierer muss man je nach Teamgrösse eine zweite Sprache lernen (Stored Procedures Programmierung)
  • Testbarkeit – Das Testen von Stored Procedures und Datenbanken gestaltet sich komplizierter
  • Es ist nicht mehr klar, wo die Business Logik ist. Einmal ist sie in der DB, das andere mal im Sourcecode
  • Validierungen und Funktionen auf der gleichen Abstraktionsebene werden auf verschiedene Applikationsschichten verteilt.
  • Debugging wird komplexer ( Eine Logiksequenz läuft in verschiedenen Schichten ab)
  • Der Code (Stored Procedures) ist schwieriger zu schreiben und zu verstehen, auch ist momentan die Unterstützung durch IDE’s nicht so gut, wie bei Programmiersprachen
  • Verletzung Separation of concerns – Die Hauptaufgabe einer Datenbank liegt in der Persistierung der Daten
  • Das Refactoring wird durch die verschiedenen Schichten erschwert

Persönliche Meinung

Meiner Meinung nach gilt hier das Mantra Nr. 1 der Softwareentwicklung – It depends

Die aufgezählten Nachteile in der vorhergehenden Liste überwiegen für mich. Daher bevorzuge ich grundsätzlich, so wenig Logik wie möglich in die Datenbank auszulagern. Die Abhängigkeiten sollten somit kleiner sein und dadurch werden einige SOLID Prinzipien gestützt.

Es gibt aber auch Fälle, wo ich gewisse Logik in die Datenbank auslagern/einlagern würde. Zum einen würde ich komplexe Berechnungen (z.B. Bäume) in der Datenbank ansiedeln, weil dies häufig eine andere bzw. berechnete Sicht auf die Daten darstellt. Andererseits würde ich bei Performanceengpässen Logik in die Datenbank auslagern. Dies aber nur, wenn es wirklich nicht anders geht.

Feedback

Natürlich würde es mich auch brennend interessieren, wie ihr das so handhabt? Welche Variante bevorzugt ihr wann und warum?

33 Responses

  1. Hi! Schön dass du das aufgreifst und mal paar relevante Punkte aufzählst, hatten ja schon hier ein bisschen diskutiert. Ich denke mir, dass es in Situationen, in denen die Einhaltung von SOLID mit zu vielen Schmerzen verbunden wäre, durchaus okay ist davon abzuweichen. Zum Beispiel sollte man tunlichst unterlassen, softwareseitig Konsistenzen sicherzustellen. Die Datenbank ist schließlich kein dummer Container! Was Stored Procedures angeht, hat es Hasso Plattner mal als “größten Fehler seiner Karriere” bezeichnet, darauf verzichtet zu haben. Für besonders rechenintensive Aufgaben kann man das schon vertreten. Wenn allerdings an jeder Ecke Stored-Procedures hängen, sieht keiner mehr durch. Deswegen schließe ich mich deinem “It depends”-Fazit gerne an 😉

  2. Yes, it depends. Normalerweise verwendet man keine Stored Procedures, von einigen spezial gelagerten Fällen je nach DBMS abgesehen.

    Viel wichtiger ist es eine sinnvolle Struktur zu haben ggf. sogar mit Foreign Keys. Daran scheitern 90% der Projekte bereits.

    Trigger sind hin und wieder sinnvoll, um z.B. ON UPDATE alte Daten in eine Archiv-Tabelle zu schreiben und somit die Nachvollziehbarkeit von Änderungen sicherzustellen.

    Extrem wichtig und oft unterschätzt sind Views, weil man damit vermeidet extrem lange SQL Statements direkt im Source-Code vorhalten und pflegen zu müssen und man auch mit den DB-Tools darauf zugreifen kann.

    Ich würde also das Thema Logik in der Datenbank nicht nur auf die ungeliebten Stored Procedures reduzieren. Mit deklarativem SQL ist schon sehr viel möglich und effektiv umsetzbar, was viele Entwickler sonst gerne und unnötigerweise in ihren PHP/Python/Java/…-Code schreiben.

  3. Hi Zusammen

    Danke fürs Feedback.

    Ja, es ist natürlich extrem wichtig, eine sinnvolle Struktur bei der DB zu kreiren, hat aber nichts mit der Entscheidung zu tun, ob jetzt Logik innnerhalb oder ausserhalb der DB gehört.

    Ich bin auch der Meinung, dass man Views nutzen muss. Sind aber meiner Meinung nach kein Bestandteil der Logik sondern nur eine andere Sicht auf die Daten.

    Bei ON DELETE CASCADE oder ON UPDATE CASCADE bin ich mir aber bereits am überlegen, ob dies Sinn macht in der Datenbank. In diesem Fall benötige ich bereits Wissen über das Verhalten bei der Datenbank.

  4. Wiederverwendbarkeit, wenn die DB ausgewechselt werden soll

    “Wenn” – wenn ich das schon lese. Wie oft passiert das denn im realen Leben/Berufsalltag? Wenn man nicht gerade eine Anwendung wie WordPress oder Magento entwickelt, die auf Millionen unterschiedliche Nutzer abzielt, welche dann auch noch die Installation selbst vornehmen und daher die Wahl des DBMS frei seien sollte, bleibt es doch ansonsten immer genau ein DBMS.
    Und wenn schon das DBMS so einfach gewechselt werden soll, warum besteht dann die Möglichkeit zwischen PHP und Python zu wählen?
    Dieses Argument halte ich daher für völlig haltlos, aber mir war klar, das es in der Liste der Nachteile (wiedermal) ganz oben steht.

    Es ist nicht mehr klar, wo die Business Logik ist. Einmal ist sie in der DB, das andere mal im Sourcecode

    Klare Festlegung wie bei jedem Projekt. Argument scheint mir sehr an den Haaren herbeigezogen.

    Verletzung Separation of concerns – Die Hauptaufgabe einer Datenbank liegt in der Persistierung der Daten

    Und in der Überwachung der Richtigkeit der Daten! Es ist doch keine alte Diskette, auf der wir etwas speichern und dann hoffen, später wieder etwas lesen zu können.

    auch ist momentan die Unterstützung durch IDE’s nicht so gut, wie bei Programmiersprachen

    Dafür gibt es doch mehr als genug vernünftige Software. Microsoft zeigt hier mit dem “SQL Server” wie es gehen kann. Man darf natürlich MySQL und sein Software-Angebot hier nicht vor Augen haben!

    Das Refactoring wird durch die verschiedenen Schichten erschwert

    Ganz im Gegenteil, es kann sogar vereinfacht werden. Eine saubere Absteckung der Grenzen vorausgesetzt.

  5. Bei ON DELETE CASCADE oder ON UPDATE CASCADE bin ich mir aber bereits am überlegen, ob dies Sinn macht in der Datenbank. In diesem Fall benötige ich bereits Wissen über das Verhalten bei der Datenbank.

    Oh oh oh! Tut mir leid das sagen zu müssen, damit hast du dich leider selbst disqualifiziert.
    Einschlägige Literatur zum dem Datenbanken (und hier ist das darunterliegende System irrelevant) wird dich eines Besseren belehren.

  6. Hi Carsten

    Danke für Dein Feedback, ich versuch mal so gut wie’s geht zu Antworten 🙂

    Ich gebe dir Recht, dass die Wiederverwendbarkeit der DB ein eher schwaches Argument ist. Es wird aber immer und überall genannt. Ausserdem habe ich bei meinem aktuellen Arbeitgeber genau einen solchen Fall.

    Bezüglich der Businesslogikverteilung zwischen DB und Code. Natürlich kann man es festlegen, trotzdem erhöht es die Komplexität. Und ich bin eher ein Freund von einfachen Lösungen, so lange es möglich ist.

    Was hat die Überwachung der Richtigkeit der Daten mit Businesslogik zu tun? Das Argument verstehe ich nicht.

    Ich arbeite beruflich auch mit dem SQL Server und dem PL/SQL Developer bei Oracle. Trotzdem empfinde ich die Entwicklung mit diesen Tools deutlich mühsamer, als mit IDE’s wie Netbeans und Eclipse.

    Kannst Du bezüglich Refactoring ein Beispiel machen, wo es einfacher wird?

    Bei der CASCADE Geschichte… das ist einfach mein persönliches Gefühl – Ich habe aber auch geschrieben, dass ich mir am überlegen bin, ob dies Sinn in der Datenbank macht oder nicht. Mir ist schon klar, dass es z.B. bei einer Aggregation durchaus Sinn machen kann.
    Aber wenn du schon auf einschlägige Literatur verweist ( da ich mich ja selber disqualifiziert habe), wäre ich froh, wenn Du mir einen Verweis geben könntest, so dass ich meine Wissenslücke schliessen kann.

  7. Jede Software bietet eine “Sicht auf die Daten”. Wenn die Datenbank ohne äußere Events anfängt Daten anzulegen oder zu ändern, sollte man sich Gedanken machen, ob nicht evtl. das Filesystem defekt ist.

    Auch bei deklarativem SQL gibt es ein “Verhalten bei der Datenbank”, z.B. wenn ein CASE in der VIEW Definition steckt oder ganz trivial in einem JOIN bei der Business-Entscheidung welche Adresse einem Kunden für den Versand zugeordnet werden soll.

  8. Da ich weiss, von welchem Beispiel DaRaff redet kann ich vielleicht ein bischen erläutern was denn so alles in der DB drinnsteckt:
    In der Datenbank wurden z.B. folgende Teile komplett eingebaut:

    * kompletter Import und Export per XML: Die Business-logik kann den Prozess nur anstossen und hoffen dass es irgendwann fertig ist und die DB ein XML-File ins Dateisystem geschrieben hat.

    * die ganzen SQL-Queries sind wiederum auch in einer Datenbanktabelle abgelegt, wodurch man als Programmierer der Applikationslogik keine Ahnung hat was genau passiert, und wenn man ihn ändert, kann an irgend einer anderen Ecke etwas kaputt gehen (deswegen schlecht für Refactoring)

    * es werden direkt in der Datenbank PDF-Seiten erzeugt, anhand der Daten und einer Definiton per XML

    * gewisse Daten werden durch etwa 5 verschachtelte Views geholt

    * Schnittstellen zu anderen Programmen werden direkt auf die DB gemacht, ohne dass die Applikation etwas zu entscheiden hat. Eine Änderung der Datenstruktur bedeutet dann auch, dass externe Partner ihre Schnittstellen jedesmal auch anpassen müssen.

    Alles in allem wurde praktisch die ganze Ablauflogik in die DB verfrachtet, und die eigentlich Applikation darf nur noch ein bischen das Frontend bedienen. Von der ganzen schönen objektorientierte Programmierung und die Unittests der Applikation kann man in der Datenbank dann nicht profitieren.

    Ich finde auch, dass Views, die Konsistenz und auch eine gewisse Aufarbeitung der Daten die Aufgabe der DB ist, aber wenn der ganze Programmablauf praktisch nur noch in der DB stattfindet, finde ich es etwas übers Ziel hinausgeschossen…

  9. Hi DaRaFF,
    nachdem Michael so freundlich war ein paar Punkte aufzählen, die dich (wahrscheinlich) zu Bedenken bzw. zu diesen Überlegungen führen, dann ist mir das jetzt klar.
    Natürlich ist das ordentlicher Käse:

    die ganzen SQL-Queries sind wiederum auch in einer Datenbanktabelle abgelegt

    …wenn nicht sogar schon kriminell!
    Und wenn Daten durch mehrere Sichten geschliffen werden, dann kann das auch nicht übersichtlich sein oder gar irgendeiner Logik folgen.

    Kannst Du bezüglich Refactoring ein Beispiel machen, wo es einfacher wird?

    Behandelt man die Datenbank als eine weitere Schicht der Applikation, beispielsweise zusätzlich zu MVC, und man hat die Schichten sauber “getrennt”, dann kannst du deine Datenbank ändern ohne das du etwas in PHP anfassen musst.
    Oder vielleicht noch etwas greifbarer: regelst du mit Prozeduren den Schreibzugriff und das Lesen mit Sichten und Prozeduren, dann hast eine schöne Schnittstelle. Im einfachsten Fall ist es nur eine Fassade vor den eigentlichen Datenbanktabellen.

    Und wenn wir schon bei Microsoft sind, warum nicht die Benutzeranmeldung – auch über den Browser – durchreichen und die SQL-Server den Zugriff regeln lassen? Der kommt doch an die Konten (im Intranet) ohne Probleme.

    Ich arbeite beruflich auch mit dem SQL Server und dem PL/SQL Developer bei Oracle. Trotzdem empfinde ich die Entwicklung mit diesen Tools deutlich mühsamer, als mit IDE’s wie Netbeans und Eclipse.

    Ich meinte eigentlich eher: SQL-Server-Tools für Datenbank und Netbeans für PHP. Zwei unterschiedliche Systeme, also auch zwei unterschiedliche Werkzeuge.
    Schau mal bei “Visual Studio” rein, vielleicht hilft dir das schon.

    Danke nochmals an Michael für die Aufklärung. Haut dem “Verbrecher” das aber nochmals auf den Tisch, das ist richtig Unsinn und ist weit entfernt jedweder Logik.

    Gruß
    Carsten

  10. Naja, wenn der Datenbank-Server eine ordentliche XML-Unterstützung mitbringt ist gegen XML und XSL für Import/Export sowie XML und XSL-FO für die PDF-Dokumente grundsätzlich nichts einzuwenden. Ein paar Zeilen PHP tun’s im Zweifel natürlich auch (zumal PHP gratis XML und XSL Support hat) und das vermutlich zu einem Bruchteil der Kosten. Auch gegen verschachtelte Views kann man nur einwenden, dass es irgendwann sehr langsam wird.

    Der Punkt “Schnittstellen zu anderen Programmen [von externen Dienstleistern] werden direkt auf die DB gemacht” ist wesentlich problematischer, aber dazu gibt es genug Literatur und das hat auch nichts mehr mit Stored Procedures und SQL zu tun.

  11. Ich persönlich tendiere eher zur Software-seitigen Arbeit. Was natürlich kein „SELECT *“ bedeutet. Aber bspw. das bei http://www.d-mueller.de angesprochene „SELECT price*1.95583 AS europreis“ lässt die Logik in der Anwendung und lagert nur einen Teil der Arbeit in die Datenbank aus. Das finde ich einen guten Weg.
    Bei anderen Themen wie restriktive Datentypen oder FK-Konsistenz kann man natürlich nicht mehr so einfach agieren. Wenn die Performance kein arger Faktor ist, würde ich allerdings immer in Richtung Übersichtlichkeit/Wartung argumentieren.

    „Und in der Überwachung der Richtigkeit der Daten! “
    Also IMHO kann die Datenbank außer verwendeten Datentypen doch gar nichts wissen über „richtige“ Daten in der Businesslogik. Valide werden die Daten doch erst im Kontext. Zudem sollte die Businesslogik die Schnittstelle sein, also ist es für mich theoretisch sehr gut denkbar, dass sich im Zuge eines Umbaus der Implementierung auch das zugrundeliegende DB-Schema grundlegend ändern kann.

    „Einschlägige Literatur zum dem Datenbanken“
    Hier geht es aber um die Betrachtung des Gesamtsystems. Klar wird ein dezidierter Datenbankentwickler immer auf die großartigen Möglichkeiten seiner Software verweisen und auch empfehlen, die Features zu nutzen. Flexibler ist allerdings IMHO, den „Verstand“ der Businessschicht eine Ebene höher anzulegen.

  12. Religious crap statement No. 1 of software development:
    It depends.

    1st axiom of an enterprise domain model:
    There is no database.

  13. Also IMHO kann die Datenbank außer verwendeten Datentypen doch gar nichts wissen über „richtige“ Daten…

    Die Datenbank kann genauso viel wissen wie deine Anwendung. Du musst es ihr nur beibringen, so wie du es auch bei der Anwendung machen würdest.

    Flexibler ist allerdings IMHO, den „Verstand“ der Businessschicht eine Ebene höher anzulegen.

    Ganz einfaches Beispiel: Du hast eine Website, eine iPhone-Anwendung und eine Desktop-Anwendung. Alle greifen auf die gleiche Datenbank zu. Es wird eine Preisberechnung in verschiedenen Währungen benötigt und auch unterschiedliche Zeitzonen müssen beachtet werden. Was ist jetzt flexibler? Jeweils die Berechnung in die Client-Anwendung gepackt oder einmal in der Datenbank hinterlegt? Übrigens steht noch eine Android- und eine Playbook-Anwendung an.
    Womit wir auch wieder beim Thema “Refactoring” wären.

    1st axiom of an enterprise domain model:
    There is no database.

    Habe ich etwas überlese? Oder hat jemand das Domain Model in Frage gestellt?

  14. @Carsten

    Ja, fast alle haben das DM in Frage gestellt.
    In dem sie die Businesslogik an “Fremdleister” vergeben haben und damit die Kontrolle aufgeben.

    Eine Anwendung, die ein gewisses Maß an Komplexität der Businesslogik besitzt, sollte nicht unter externen Concerns wie Persistierung, Authentifizierung, etc. gestaltet werden. Ein gutes Geschäftsmodell muss auch ohne dies funktionieren.
    Und Logik in der Datenbank hintergeht eben dies.

    SoC sollte auch auf Architekturebene *konsequent* durchgezogen werden, wahrscheinlich noch stärker als in der Programmierung.

  15. @Don: Die Frage ist natürlich was hier als “Businesslogik” bezeichnet wird. In jedem Fall sollte man Produkte so benutzen, wie sie gedacht sind und eine SQL-Datenbank ist mehr als eine reine Datenablage. Meine Kommentare will ich allerdings nicht nutzen, um sämtliche Abhängigkeiten und das theoretische Fundament aufzuzeigen.

    Schreib doch auch einen Blog-Post mit Deinen ganzen Bedenken und Einsichten! 🙂

  16. @Michael

    Ich kann nicht beantworten, was deine Businesslogik sein könnte.
    Aber wer es nicht für sich selbst beantworten kann, hat sowieso ein Problem.

    Recht einfach kann man aber beantworten, was die eigene BL im Sinne von Wichtigkeit oder Andersartigkeit ausmacht.
    Amazon z.B. ist ein simpler Buchhändler, das können andere auch und Shopsysteme dafür gibt es genug. Was sie aber anders bzw. forciert und richtig gut gemacht haben, dass sie von anderen unterscheidet, ist z.B. das Vorschlags- und Rezensionsystem. Das haben sie perfektioniert (neben vielen anderen Dingen).
    Und das Erfolgsgeheimnis von Twitter ist die Limitierung auf 140 Zeichen und nicht, wo und wie diese Nachrichten gespeichert werden. Im Prinzip müsste man sie garnicht persistieren, oder?

    Für deine eigene BL kannst du im Prinzip einfache Fragen stellen:
    „Warum kann ich nicht ein Produkt von der Stange kaufen oder ein Standardtool nehmen, das diese Aufgabe löst?“
    Damit oder auch nach und nach findest du heraus, was der eigentliche Kern deiner BL ist und worauf du dich besonders konzentrieren solltest.

    Und zurück zum Thema: nur weil wir wissen, dass wir die Vorgänge unserer Geschäftsmodells evtl. persisitieren wollen, bleibt es dennoch eine komplett andere Anforderung, die die Grundlagen unserer BL nicht berührt.
    Wird es eine relationale Datenbank sein oder eine Key-Value-Store oder Excel- oder gar handgeschriebene Listen oder garnichts?

    Würden wir besonders günstig Bücher anbieten, könnten wir dies auch auf Flohmärkten mit Barzahlung machen. Unser Geschäftsmodell wäre nicht, die Listen vorhandener Bücher zu speichern, sondern viele Bücher gewinnbringend an den Mann zu bringen.
    Denn letztendlich zählen die Ergebnisse (i.d.R. also die Verkafuszahlen und die Kasse).
    Ein guter Verkäufer oder Hersteller konzentriert sich auf die Optimierung seiner Produkte und des Verkaufens und nicht darauf, wo seine Produkte statisch abgebildet oder archiviert werden.

  17. @Don

    Ich lese jetzt hier schon eine Weile mit.
    Theorie hin oder her, aber wenn ich deiner Argumentation folge, dann sind Datenbankfeatures wie Stored Procedure völlig für die Tonne?
    Das Beispiel von Carsten mit dem iPhone-App finde ich treffend gewählt. Denn wir schreiben hier an Programmen für Smartphones und Tablets und haben ständig Probleme mit der Performance, weil die Geräte einfach zu mickrige CPUs haben. Wenn wir zentral etwas auslagern können, dann tun wir dies. Und wir müssen auch nicht bestimmte Teile des Programms in jede App einpflanzen und unzählige Apps updaten. Denn Apple braucht auch immer eine halbe Ewigkeit bis unser eingereichtes Update freigeschaltet wird.
    Wir schreiben sehr viel in PL/Python und fahren damit seit Jahren sehr gut.
    Wir haben sogar etwas für Handscanner geschrieben, die sich direkt mit der Datenbank unterhalten. Ca. 99 % des Geschriebenen liegt dabei in der Datenbank. Bei 12 Arbeitsplätzen mit je 4 Scannern sind wir froh nur an die Datenbank bei Änderungen zu müssen und nicht alle Geräte einzeln.

  18. @Achim

    Ich kann das Beispiel mit der iPhone-App irgendwie gar nicht nachvollziehen. Normal sollte die Architektur bei solchen Client/Server Anwendungen mit einer zusätzlichen Service-Schicht ausgestattet werden. Diese Service-Schicht bietet auf der einen Seite eine klare Schnittelle für die Client-Anwendungen und auf der anderen Seite eine klare Abstraktion zur Persistenz-Schicht.

  19. @Achim

    Christian hat es bereits richtig hintzerfragt.

    Gehe aber noch einen Schritt weiter und schaue dir SRP und SoC noch mal genauer an:
    Warum findet SoC nur auf Methodenebene (und selten auf Objektebene) statt, obwohl man es auch für die ganze Architektur einsetzen könnte?

    Anders gesagt: warum ist eine Klasse oder ein Modul sowohl für Transaktionen als auch für Lesevorgänge zuständig? Ist das nicht eine klare Verletzung des SRP und von SoC?
    Und nun ersetze mit oder …

    In typischen Applikationen sind 90% alle Vorgänge Abfragen bzw. Reportings.
    Und daher nur ein kleiner Teil die eigentlichen Transaktionen (commands).

    Trenne beide, mache Spezialisten daraus. Sorge dafür, dass die Konsistenz im Command-Teil bleibt und skaliere die Performanz im Query-Teil bis zum gehtnichtmehr. Notfalls auch mit separaten Datenquellen oder speziellen Tabellen für einzelne Views oder Geräte.
    Lesevorgänge beitzen keine Logik, können völlig separat behandelt werden, müssen nicht konsistent sondern nur performant sein, usw. usw.
    Schreibe Daten in ACID-konforme SQL-DBs und lese Daten aus dem Speicher, mit Hilfe von In-Memory Key-Value-Stores oder aus einer anderen SQL-DB mit Daten in der ersten Normalform.

    Es öffnene sich ganz neue Horizonte bei der Zuhilfenahme bewährter Prinzipien und der speziellen Betrachtung eigener Probleme aus einer anderen Perspektive.

  20. Mist, Teil wurde abgeschnitten, sollte heißen:

    “Und nun ersetze Klasse mit Modul oder Datenquelle …”

  21. @Christian

    Die Service-Schicht die du hier nennst, haben wir dabei in der Datenbank hinterlegt. Will heißen, wir haben mittels Prozeduren & Co. die Schnittstelle geschaffen. Warum das Ganze? Die Handscanner übernehmen die Darstellung der Daten selbst, wir haben sozusagen nur die Daten übergeben und die vorhandene Firmware machte den Rest. Wir wollten zwar erst selbst etwas zur Darstellung schreiben, aber das Dagewesene funktionierte problemlos und die Mitarbeiter kannten die Oberfläche. Nun stellten wir aber fest, wenn wir vor der Übergabe der Daten noch unsere Verarbeitung auf dem Gerät durchführen, kommt es zu sichtbaren Verzögerung – die Anwendung blieb kurz hängen. Nun war klar, wir müssen das auf den Server auslagern. Jetzt stellt sich zusätzlich heraus, das der Server auf dem die Datenbank lief mehr Power hat und kaum bis gar nicht belastet ist – im Gegensatz zum anderen Server.
    Somit schoben wir fast alles in die Datenbank. Natürlich sauber getrennt, ohne Trickserei und sogar mit Versionsverwaltung für das Datenbankschema. Am Ende ist es nicht nur schön geworden, sondern richtig performant. Das Ding rennt und der Datenbank juckt es kaum, das sie jetzt noch mehr macht.

    @Don

    In typischen Applikationen sind 90% alle Vorgänge Abfragen bzw. Reportings.
    Und daher nur ein kleiner Teil die eigentlichen Transaktionen (commands).

    Trenne beide, mache Spezialisten daraus. Sorge dafür, dass die Konsistenz im Command-Teil bleibt und skaliere die Performanz im Query-Teil bis zum gehtnichtmehr. Notfalls auch mit separaten Datenquellen oder speziellen Tabellen für einzelne Views oder Geräte.
    Lesevorgänge beitzen keine Logik, können völlig separat behandelt werden, müssen nicht konsistent sondern nur performant sein, usw. usw.
    Schreibe Daten in ACID-konforme SQL-DBs und lese Daten aus dem Speicher, mit Hilfe von In-Memory Key-Value-Stores oder aus einer anderen SQL-DB mit Daten in der ersten Normalform.

    Es öffnene sich ganz neue Horizonte bei der Zuhilfenahme bewährter Prinzipien und der speziellen Betrachtung eigener Probleme aus einer anderen Perspektive.

    Kein Angst, das ist unsere tägliche Arbeistweise und alles bekannt und geschätzt.
    Nur weil wir sehr oft etwas aus performancetechnischen Gründen entscheiden müssen, fangen wir nicht an zu frickeln oder gar Regeln über Bord zu werfen.

  22. Ich habe bei den Antipatterns in Wikipedia noch einen treffenden Abschnitt gefunden:

    Zitat:
    Sumo-Hochzeit (engl. Sumo Marriage)
    Ein Fat Client ist unnatürlich stark abhängig von der Datenbank. In der Datenbank ist sehr viel Logik in Form der datenbankeigenen Programmiersprache positioniert, in Oracle zum Beispiel mit PL/SQL. Die ganze Architektur ist sehr unflexibel. Soll die Anwendung zu einer Internet-Anwendung migriert oder die Datenbank gewechselt werden, so müssen auf beiden Schichten (Client und Datenhaltung) viele Bereiche neu entwickelt werden. Die Systeme sind nicht entkoppelt.

    http://de.wikipedia.org/wiki/Anti-Pattern

  23. Sumo-Hochzeit (engl. Sumo Marriage)
    Ein Fat Client ist unnatürlich stark abhängig von der Datenbank. In der Datenbank ist sehr viel Logik in Form der datenbankeigenen Programmiersprache positioniert, in Oracle zum Beispiel mit PL/SQL. Die ganze Architektur ist sehr unflexibel. Soll die Anwendung zu einer Internet-Anwendung migriert oder die Datenbank gewechselt werden, so müssen auf beiden Schichten (Client und Datenhaltung) viele Bereiche neu entwickelt werden. Die Systeme sind nicht entkoppelt.

    Carsten hatte oben ein Beispiel genannt, was die Sache aber genau umdreht:

    Ganz einfaches Beispiel: Du hast eine Website, eine iPhone-Anwendung und eine Desktop-Anwendung. Alle greifen auf die gleiche Datenbank zu. Es wird eine Preisberechnung in verschiedenen Währungen benötigt und auch unterschiedliche Zeitzonen müssen beachtet werden. Was ist jetzt flexibler? Jeweils die Berechnung in die Client-Anwendung gepackt oder einmal in der Datenbank hinterlegt? Übrigens steht noch eine Android- und eine Playbook-Anwendung an.
    Womit wir auch wieder beim Thema “Refactoring” wären.

    Das würde ich sogar als Vorteil sehen, auch wenn ich nicht weiß wie man das umsetzen sollte.

  24. Irgendwie habe ich das Gefühl wir reden aneinander vorbei:

    Es wird versucht zwei völlig verschiedene Arten von Anwendungen zu vergleichen:
    1. Client kommuniziert direkt mit der Datenbank (Handscanner, Ipad, Desktopanwendung)
    2. Client Kommuniziert mit Applikationsserver, der wiederum mit der Datenbank kommuniziert (Webanwendung und DaRaffs ursprünglicher Artikel).

    Das im ersten Fall der Client zu lahm für Berechnungen sein kann, und gewisse Sachen zentral gelöst werden sollten leuchtet mir ein. Darum bin ich bei der Architektur einer Anwendung mit verschiedenartigen Clients eher für die zweite Variante, wo man Gemeinsamkeiten, Abläufe, Schnittstellen und eigentlich alles was nicht direkt mit den Daten zu tun hat im Applikationsserver ansiedeln kann (ob dies nun Java, PHP, dotNet oder was auch immer ist).
    Ich habe bis jetzt noch keine Webanwendung gesehen, die direkt mit dem Datenbankserver kommuniziert.

  25. Kann denn jemand konkrete nachteile nenne, die sich ergeben, wenn man mit einer GUI “direkt” auf den Daten arbeitet? Ich meine, in der Uni hab ich auch die MVC usw…gelernt, aber was sind denn mal konkrete Nachteile?

  26. Im Prinzip einfach:
    Einige Kernprinzipien von OOP sind Verantwortlichkeit über seine eigenen Zustände (und Daten), Kapselung und Information Hiding, und so sollte es auch mit einer Architektur geartet sein.
    In deinem Fall wüsste bzw. vermutet deine GUI wie Zustandsänderungen, Geschäftslogik und die Zusammenhänge von Daten aussehen. Ändert sich das aber, dann kracht es.
    Das ist eine Verantwortung des Models, die wiederum von den Controllern gesteuert wird, um bei MVC zu bleiben.

  27. @MASON
    Don Zampano hat’s schon gut beschrieben, aber ich versuchs mal mit möglichst einfachen Worten.

    Nachteil 1:
    Wenn Du etwas ändern musst, musst Du es an vielen Stellen machen, weil die Verantwortlichkeiten durchmischt sind. Daraus folgt, dass die Anfälligkeit auf Fehler steigt.

    Nachteil 2:
    In einer Architektur, wo alles durchmischt ist, ist es sehr schwierig automatisierte Tests zu schreiben. Daraus folgt, dass Du entweder langsame Tests (mit GUI Testing Tools) hast, oder von Hand testen musst. Das kostet Dich viel Geld.

  28. ok, vielen dank! Ich habe hier nämlich gerade ein kleines Tool was zu “reviewn” ist. Es hat mega Performance Probleme( .Net GUI, holt Daten aus Oracle 11g). Die Logik ist nicht so komplex, also der user soll Daten einfach nur auswählen und nachträglich klassifizieren…(gut/schlecht markieren). Aber irgendwie macht das Ding Probleme (schon bei 4 Usern) und nun überlege ich , ob das ne vernünftige Architektur verpasst bekommt… =)

  29. I see you share interesting things here, you can earn some extra cash, your website has huge potential, for
    the monetizing method, just type in google – K2
    advices how to monetize a website

  30. I read a lot of interesting posts here. Probably you spend a
    lot of time writing, i know how to save you a lot of work, there is an online tool that creates high quality, google friendly articles in minutes, just search
    in google – laranitas free content source

Leave a Reply

Your email address will not be published. Required fields are marked *