Separate Berichtsdatenbanken

Bild
Mainboard CD

Das typische Szenario einer Webanwendung sieht so aus: Ein paar PHP Scripte greifen auf eine Datenbank zu, in denen die gesamten Daten einer Applikation vorgehalten werden. Wenn es sich um eine gute Applikation handelt, implementieren diese Scripte das Domain Modell. Das Domain Modell ist hervorragend dazu geeignet die gesamte Business Logik zu implementieren und auch Berichte für den User zur Verfügung zu stellen. Es gibt jedoch 2 Szenarien, die es eventuell notwendig machen dieses Standard-Szenario weiter zu entwickeln.

In einer großen Webanwendung gibt meist zwei Formen von deren Nutzung. Zum einen ist das die Pflege der Daten, also Eingabe, Änderungen und Löschen von Daten. Zum anderen gibt es das Auswerten der vorhandenen Daten in Form von Berichten. Je nach Komplexität der Berichte können diese schnell sehr resourcenaufwendig sein.

Des weiteren können manche Berichte so aufwendig sein, das sie sich nicht mehr auf einfache Weise mit dem Domain Modell abbilden lassen, sondern das Ausführen von speziellen SQL Kommandos notwendig wird.

In diesen Fällen ist es sinnvoll sich über die Verwendung einer separaten Berichtsdatenbank Gedanken zu machen. Natürlich sollte man noch einmal in sich gehen, in vielen Fällen ist die Notwendigkeit von speziellen SQL Kommandos ein Anzeichen dafür, dass man sich die Anforderungen der Applikation nicht in der notwendigen Tiefe angeschaut hat. Dies ist aber nicht in jedem Fall so und dann kann es sinnvoll sein eine separate Berichtsdatenbank anzulegen.

So eine Berichtsdatenbank ist eine separate Datenbank, die von der aktuellen Datenbank, die die operativen Daten vorhält, getrennt ist. Diese Berichtsdatenbank wird von Code gefüllt, der innerhalb des Domain Modells ausgeführt wird und so vom Domain Modell abgeleitete Daten in die Berichtsdatenbank einfügen kann. Dies hat mehrere Vorteile:

  • Man braucht sich nicht um die Normalisierung der Berichtsdatenbank zu kümmern, denn aus dieser wird nur gelesen.
  • Man kann die Struktur der Berichtsdatenbank so anpassen, dass sie den Anforderungen der Berichte besser entspricht, als dies mit der Produktivdatenbank möglich gewesen wäre.
  • Man kann die Produktivdatenbank anpassen, ohne dass dies das Berichtswesen beeinträchtigen würde.
  • Abfragen, die die Berichtsdatenbank betreffen verlangsamen nicht länger das Produktivsystem

Eines der Probleme bei diesem Angang ist sicherlich, das die Daten in der Berichtsdatenbank aktuell gehalten werden müssen. In vielen Fällen ist es hierzu ausreichend, wenn man einfach nachts einen Batch Lauf anstößt, der die Daten aus der Produktivdatenbank in die Berichtsdatenbank kopiert. Wenn Berichte den Datenstand vom Vortag wiederspiegeln ist dies in den meisten Fällen ausreichend.

Benötigt man aktuellere Daten, ist es sinnvoll sich genau anzuschauen, für welche Berichte dies sinnvoll erscheint, sicher nicht für alle. So kann man für die Daten, die wirklich aktuell sein müssen, eine Art Messaging System entwickeln, die die zu ändernden Daten ins Berichtssystem kopieren, sobald diese im Produktivsystem verändert werden.

Sicherlich könnte man auch mit Views arbeiten, aber diese bieten nicht den Vorteil, das man das Produktivsystem entlasten kann und die Rechenlast auf unterschiedliche Server aufteilen kann.