Wie viel Logik gehört in die Datenbank?

Ja, schon einiges!

Gerade hatte ich ein spannendes Online-Seminar zum Thema SQL Server Performance und Monitoring. Dabei hat mich ein Teilnehmer gefragt, wie viel Logik in die Datenbank integriert werden sollte.

Zunächst möchte ich festhalten: Eine Datenbank kann mehr als nur SELECT, INSERT, UPDATE und DELETE. Ich halte es für falsch, sämtliche Datenprüfungen, Konsistenzprüfungen und Datenmanipulationen ausschließlich in die Applikation zu verlagern.

Stellen Sie sich vor, Sie haben eine Tabelle, in der protokolliert wird, wer einen Datensatz wann angelegt und wann er zuletzt von wem geändert wurde. Ihre Datenbank wird von einer Full-Client-Applikation aufgerufen, und nun soll es zusätzlich eine Webapplikation oder vielleicht eine App für Smartphones geben, die ebenfalls auf diese Tabelle zugreift und Datenmanipulationen ermöglicht.

Die gesamte Logik, wer wann die Daten manipuliert hat, müsste dann nicht nur im Full-Client, sondern auch in der Webapplikation und der App implementiert werden. Ganz zu schweigen davon, dass berechtigte Mitarbeiter die Daten möglicherweise über ein Abfragetool verändern könnten – in diesem Fall greifen die Regeln der Applikationen nicht, da diese gar nicht verwendet werden.

Liegt diese Logik jedoch in der Datenbank, muss sie nur einmal erstellt und gewartet werden. Dies führt oft zu weniger Transaktionen, und der Datenverkehr zwischen Datenbankserver und Applikation ist geringer, da einige der Datenzugriffe direkt in der Datenbank erfolgen.

Mein Fazit: Nutzen Sie Default Constraints, Check Constraints, Unique Constraints/Indizes (abhängig davon, wie Ihr RDBMS [relationales Datenbank-Management-System] sie nennt), DML-Trigger und Foreign Key Constraints, um die Qualität Ihrer Daten zu verbessern. Dadurch verhindern Sie auch, dass Regeln mehrfach implementiert werden müssen.

Nicht zuletzt können viele der genannten Mechanismen in der Datenbank konfiguriert werden, was aufwändiges Programmieren der Funktionen in den Applikationen erspart.