wir stehen vor der Wahl, ob wir die Funktion zur Berechnung eines Preises im Code hinterlegen oder lieber als Stored Procedure auf dem Datenbankserver. Für die Datenbank spricht die höhere Geschwindigkeit. Allerdings zerpflückt man auch den Code. Im Quell-Code hätte man zmindest "alles zusammen", allerdings müssten wir dabei Kompromisse bezüglich Geschwindkeit machen und hätten deswegen mehr Programmieraufwand, um die benutzerfreundliche Bedienung zu erhalten.
Nun wollte ich nach Eurer Meinung fragen, wenn man das Augenmerk auf saubere Architekturen legt.
Zum Teil hast du dir die Antwort schon selbst gegeben. 1. Bei performancekritischen Berechnungen bleibt dir nur der Datenbankserver übrig. Ansonsten gehören Berechnungen meiner Meinung nach in den BusinessLayer. 2. Ich würde noch einen zweiten Fall betrachten: Ist in der Datenbank ein Feld mit der Länge x und ein Feld mit der Breite y und du benötigst oft die berechnete Fläche, dann sehe ich kein Problem darin, dies im Datenbankserver zu ermitteln. Das Ergebnis ist selbsterklärend. Besteht diese Berechnung aus umfangreicher Logik oder mehreren Parameter, würde ich die Berechnung im BusinessLayer durchführen. Dort ist die Berechnung für weitere Entwickler schnell nachvollziehbar.
Gerade kam ich per Twitter zu diesem passenden Artikel: With so much pain, why are stored procedures used so much http://www.sadalage.com/2011/01/with-so-much-pain-why-do-we-st.html
ich bin da für die Datenbank (am ehesten sogar per Trigger) da somit die Daten immer konsistent sind. ZB wenn per Management-Studio in den Daten gewerkt wird od. ein anderer Client darauf zugreift, ohne den Preis zu berechnen, dann garantiert der Trigger dass es passt.
in der DB funktionieren berechnete Felder zugegeben sehr gut, Berechnungen sind die Stärke von T-SQL (im Gegensatz zu Stringoperationen).
Jetzt kenne ich Dein Anwenungsszenarion nicht genau. Möchtest Du tausende von Preisen neu berechnen? Je komplizierter die Berechnung umso eher würde ich das wieder im Code durchführen lassen, da das deutlich überisichtlicher ist. Und: Du benötigst bei der Berechnung durch den SQL Server wahrscheinlich mehr Roundtrips zwischen Anwendung und DB Server.
Du kannst im Code (wenigstens mit .Net 4.0) auch schnell mit Task arbeiten und die Berechnung parallel durchführen lassen.
Wenn ich vor der Aufgabe stünde:
Pro NET: - Berechnung sehr komplex - Daten werden jetzt in der Anwendung benötigt (weniger Roundtrips) - Einheitliche Stelle an der der Code liegt
Pro SQL: - Massenupdate - Performanceengpässe in der Anwendung
vielen Dank für eure Antworten. Mir ging es wirklich erstmal grundsätzlich darum, ob gegen die Auslagerung auf die Datenbank etwas spricht. Für mich klingt das nun eher für die Datenbank, zummal auch wenige Parameter aus dem Programm und die meisten Daten schon in der DB liegen.
Zuerst das Programm korrekt schreiben, dann erst an die Geschwindigkeit herangehen. "Strive to write good programs, rather than fast ones." (Effective JAVA, Joshua Bloch) "Gute" oder korrekte Programme orientieren sich an Richtlinien wie Modularisierung (klare Verantwortungen), Normalisierung (wenig Redundanzen), Transparenz (keine Hintertüren, keine Magic Numbers/Strings) und durchdachte Schnittstellen.
"Strive to avoid design decisions that limit performance." (Effective JAVA, Joshua Bloch) Man sollte sich durch Designentscheidungen nicht die Möglichkeit der Optimierung nehmen.
Ich stimme zu, dass die Datenbank die Berechnungen sehr schnell macht. Dennoch würde ich die Performanceeinbußen eines Business-Layers in einem Application-Server in Kauf nehmen, um damit der klaren Verantwortlichkeit genüge zu tun. Damit erübrigt sich das Suchen "wo" Dinge implementiert sind. Wenn man massiven Einsatz von Stored Procedures und Trigger proklamiert, dann sollte man auch B sagen und den Business-Layer komplett in der DB über Procedures und Trigger realisieren. Ich sage nicht, dass man besser die Business-Logik dort oder dort ansiedelt. Es geht mir nur um die konsequente Verfolgung der Entscheidung, damit keine Verteilung der Business-Logik über mehrere Schichten erfolgt.
Für den Einsatz außerhalb der DB spricht, dass man sich auf einer höhren Abstraktionsebene befindet und damit nicht mehr so abhängig ist von Schemaänderungen. Des Weiteren würde ich Skalierbarkeit ansprechen, was mit modernen Application-Servern besser möglich ist.
Sollte wirklich an bestimmten Stellen ein Flaschenhals entstehen, so ist eine Streuung der Business-Logik legitim, wenn es nicht anders lösbar ist.
Da man Application-Server beliebig skalieren kann, tritt der Flaschenhals doch meistens in der Datenbank auf. Imho gibt es keinen vernünftigen Grund mehr für Business Logik in Stored Procedures. Die eleganteste Möglichkeit zur Ablage einer Preisberechnung ist meiner Meinung nach die Konfiguration.
Die Konfiguration wäre aus meiner Sicht nur adäquat, wenn eine absehbare unverselle Flexibilität in der Art der Preisberechnung gibt. Ansonsten ist die Ablage in der Konfiguration ein absolutes Anti-Pattern. An dieser Stelle muss man fairerweise sagen, dass es wenig Grauzone gibt, sondern von Best-Pactise sofort zum Anti-Pattern kippt oder umgekehrt. Wenn man Berechnungen auslagert, müssen diese wieder eingelesen und interpretiert werden. D.h. es handelt sich um eine neue Sprache. Wenn man die Flexibilität braucht ok, ansonsten Finger weg von ausgelagerten Berechnungen.
Die Wartbarkeit der Anwendung ist noch eine Überlegung wert: Wenn man ein Berechnungsschema in eine SP packt können Änderungen leicht durchgeführt werden. Nur: Wie bekommt man später heraus, auf welcher Berechnung ein in der DB gespeicherter Preis basiert? Hast du einen Changed/Created Spalte mit Trigger kann man immerhin feststellen, zu welchem Zeitpunkt der Datensatz mit dem geg. Preis angelegt wurde - nicht aber was der Inhalt der SP zu diesem Zeitpunkt war. Dafür ist eine Versionskontrolle wichtig.
