Facebook
0
Twitter
0
Google+
0
Kommentare
0

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?

flattr this!

Über den Autor

Daraff

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen