Gute Gründe für die Programmierung eines eigenen Frameworks

  • Frameworks sind mein Kerngeschäft.
  • Ich bin hyperinnovative Firma XY und habe allein schon 20 TB an Logs pro Stunde.
  • Meine Entwickler sind unterbezahlte Genies, die in ihrer Freizeit bessere Frameworks bauen als die tausenden Entwickler, die das als ihr Kerngeschäft betreiben.
  • Ich habe einen Blutpakt mit meinen Entwicklern geschlossen weswegen es nur fair ist, dass ich mich zu 100% von ihnen abhängig mache.
  • Ich bin meiner Konkurrenz so viele Lichtjahre voraus, dass ich meine Entwickler irgendwie beschäftigt halten muss, während die Welt für neue Features reift.
  • Ich möchte nie neue Mitarbeiter einstellen und wenn, werden sie die Firma nie wieder verlassen (s. Blutpakt), deswegen ist es uninteressant, dass das gelernte Framework in einem Lebenslauf absolut keine Relevanz hat und Einarbeitungszeit spielt in meinem Unternehmen keine Rolle.
  • Ich bin verdammt schlecht beraten worden.

Datenbanken sind langsam

Klar sind sie das. Datenbanken machen IO und IO ist generell nicht so wahnsinnig schnell. Und Datenbanken sind unendlich kompliziert und generell mit enorm viel Wartung verbunden und eigentlich total Überflüssig.

Für diese Probleme sehe ich bei meinen Codereviews immer wieder mehr oder minder originelle Lösungen.

Lösung: Alles im Speicher

Man verwaltet einfach alle Daten in einem großen Objektbaum, der dann hin und wieder auf die Festplatte serialisiert wird. Bei Programmstart wird das serialisierte Objekt mit allen Daten einfach geladen und Rock ’n‘ Roll.

Das funktioniert von mir aus einigermaßen mit der berühmten „Video Verwaltung“, die man gerne mal während des Studiums baut, und mag auch noch in kleinen Startups funktionieren, die einen Onlineshop mit 1000 Artikeln haben, aber da liegt dann auch schon das Problem: Bleibt es bei 1000 Artikeln, ist das Startup irgendwann Geschichte und die Lösung hat bis zum Schluss funktioniert. Der schlimmere Fall: das Startup wächst und irgendwann hat man 1 Mio Artikel. Die passen jetzt irgendwie nicht mehr in den Speicher. Mal ganz davon zu schweigen, dass das Serialisieren eines riesigen Objektbaums auf die Festplatte nicht wirklich transaktional ist. Das bedeutet, wenn etwas schief geht, geht es schief und die Daten sind weg. Konkurrierende Schreibzugriffe (Datensätze werden von mehreren Personen gleichzeitig bearbeitet) sind zwar total gut mit Time Slots zu lösen (von 9-11 Uhr darf nur die eine Abteilung ihre Daten bearbeiten, von 11-13 Uhr die nächste), aber das ist bei vielen Datensätzen nicht mehr wirklich praktikabel.

Also merke: Die Problemstellung der Video Verwaltung als Hausaufgabe während des Studiums war dazu da, grundlegende Datenstrukturen zu erklären und nicht als Lösungsvorschlag für kommerzielle Anwendungen.

Lösung: Ich suche alles selbst

Spätestens seit Hibernate ist es total einfach, Objekte statt direkt auf die Platte in eine Datenbank zu schreiben. Das ist schon mal gar nicht so schlecht. Der Vorteil ist, dass man nun Datensätze einzeln und in einer Transaktion speichert. Wenn da mal was nicht klappt, fehlt ein Datensatz, die restlichen Daten sind noch intakt. Auch können jetzt alle Abteilungen gleichzeitig an den Daten arbeiten. Das beste aber, der Code sieht fast wie normales Java aus. Die bösen Sachen übernimmt beispielsweise JPA für uns. Und da das alles so total nach Java aussieht und man total bekannte Datenstrukturen wie Listen aus der Datenbank kriegen kann, kann man da mit der hübschen for-Schleife aus Java 5 durchiterieren und sich die Daten mit if-Abfragen raus suchen, die einen interessieren.   Alles was man braucht, ist für jede Tabelle eine „finde Alles“ Methode und ab geht’s. Man kann sogar total nett mit dem Collection Framework seine Daten nach eigenen Kriterien sortieren.

Das ganze hat nur ein Problem: es ist total ineffizient und produziert Unmengen von absolut unnötigem Code.

Datenbanken machen Datensachen!

Eben weil man meist nur bestimmte Datensätze braucht, und diese nach bestimmten Kriterien sortiert sein müssen, haben vor ungefähr 500 Jahren schlaue Computerwissenschaftler die Abfragesprache (Query Language) erfunden. Ganz, ganz kalter Kaffee? Das ist schon so lange her, das kann heute gar nicht mehr rocken?

Viel, viel schlimmer: Die Sache wird seit Generationen an allen Ecken und Enden verbessert, aktualisiert, modernisiert. Man könnte davon ausgehen, dass es ziemlich schwer wird, sich als Allrounder mit einem Menschen anzulegen, der den ganzen Tag nichts anderes macht, als sich mit effizienter Datenhaltung zu beschäftigen. Im Fall von Datenbanken lagt man sich da aber mit Generationen von Entwicklern an, die unglaublich viele Arbeitsstunden in die Technik versenkt haben – und ja, die ganze Mühe kommt auch wieder raus, wenn man seine Abfragen über die dafür vorgesehene Sprache formuliert.

Klar, die muss man dafür erst mal lernen, aber der Aufwand dafür ist deutlich geringer, als das Rad jedes mal neu zu erfinden. Ein netter Einstieg in SQL ist beispielsweise Einführung in SQL. Von SQL zur Abfragesprache von JPA ist es kein weiter Weg und ein bisschen SQL können, hat noch niemandem geschadet.

Datenbanken können das wofür sie gebaut sind unverschämt gut: Daten verwalten. Und sie sind beispielsweise in Form von MySQL oder Postgesql frei verfügbar.

Selbst die klassische Video Verwaltung lässt sich super mit einer Datenbank erledigen. Natürlich will man für so eine einfache Desktopanwendung nicht unbedingt einen Datenbankserver installieren. Dafür gibt es dann embedded Datenbanken, wie z.B. DerbyDB.

Wenn man also Sachen mit Daten machen muss, nimmt man sich eine Datenbank – die kann das schon.