Schnapps und die realtionale Datenbank-Gehirnwäsche

Und jetzt mal von vorne, Schatz.

Ich befinde mich gerade noch im Urlaub und sitze über einer kleinen Zend Framework-Anwendung: Einmal Versionskontrolle auf einem Berg relationaler Daten. Höchst gruselig, weil ich dafür im Grunde MySQL für völlig idiotisch halte. Und jede andere relationale Datenbank auch. Und wenn der liebe Gott schon kein Einsehen mit mir hat, muss ich mich zur Späten Stunde auch noch fragen, ob es überhaupt noch jemanden gibt, der relationale Datenbanken wirklich braucht.

Mache ich selten im Organ des Looser-Universums: Mal tief durchgeatmet, drei schnelle Ouzo gekippt, 'ne Kippe in die Fresse und Gliffort Gilberto aufgelegt. Besser. Viel besser.

Was ich mit wirklich meine ist das Mengen-Verhältnis der mehr überflüssigen zu den eher weniger überflüssigen Daten, die von einem durchdachten, onlinetransaktional arbeitenden Datenbank-Management-Systemen verwaltet werden. Denn wenn ich mir vorstelle, dass immer noch katholische Missionare draußen herumlaufen und Naturvölker bekehren können, während die Daten von Gästebüchern auf teuren Datenbankservern gespeichert werden (oder der Treppen-Witz schlichtweg: Blogs! Zum Teufel, wer kommt auf die bekloppte Idee, für Blogbeiträge eigene Entitäten zu nutzen? Das ist obszön!), bekomme ich Durst. Viel Durst. Denn mit dem Geld, das täglich dank des Internet weltweit für relationale Datenbanken zum Fenster heraus geschmissen wird, könnte man aber sehr lässig eine kleine Eingreiftruppe finanziert haben und die katholischen Missionare in Oracle-Schulungen schicken. Alle wären besser dran. Aber das ist ja nur ein Beispiel. Man könnte mit dem Geld den Harz4-Topf aufstocken. Und damit Nachhaltig das Mantra "Lieber Harz4 als Typo3" fördern. Das würde auch die Erderwärmung reduzieren - Grüne ist Typo3 nach der Deinstallation.

Der zweite Gedanke könnte von meinem Freund Heinrich Heine kommen: Denn "das wäre ja, als sei der Topf klüger als der Töpfer", wenn wir die mehr überflüssigen Daten von einem noch überflüssigeres Management-System verwalten ließen. Und genau da kommt der Sex ins Spiel: Wieso eigentlich nicht? Wieso wählen wir als Entwickler und Architekten immer wieder persistenten Datenspeicher in Form eines relationalen Datenbanksystems? Ich ahne es nur: Weil wir irgendwann einmal einer Gehirnwäsche unterzogen worden sind. Nein nicht der Ouozo-Gehirnwäsche. Das war die Döner-Theorie, nachdem die Deutschen weniger Sex haben, wenn sie Knoblauch essen und dadurch aussterben. Die Theorie ist blanker Unfug. Und Edgar F. Codd, der Frontmann, der hinter dem relationalen Datenbankmanagement steckt, steckt sicher auch nicht dahinter. Das wäre zu banal, außerdem ist der schon tot. Und wohl auch nicht Larry Ellison (wenn gleich es dazu sicher auch eine Verschwörungstheorie gibt, die über irgendein Typo3 mit MySQL eine Gemeinde sehr spezieller Paranoiker in einem Forum oder Blog versorgt).

Ouzo, bitte. Danke. Erinnert mich gerade an die Radio-Trinkerin von Max Goldt. Die Audio-Daten sind sicher digital auch in irgendeinem BLOB gesichert. Grauenhaft.

Die Antwort auf die noch nicht gestellte Frage lautet natürlich Key-Stores. Relationale Datenbank-Gehirnwäsche muss ich aber dennoch etwas ausführen.

Weil ich nach der FH noch ein paar Ideen hatte, durfte ich für den Veteranen-Handel ein moderates Shop-System auf der Basis einer BerkelyDB entwickeln. Ich gebe zu, mein Problem war anfangs die relationale Datenbank-Gehirnwäsche aus einem Job davor, bei der wirklich mit Mengen gearbeitet wurde, nämlich mit natürlichen und juristischen Personen, die Geld bezahlen und/oder bekommen sollten - eben ein Projektabrechnungssystem für eine Firma, die wie das nach dem Zweiten Weltkrieg noch so war, wenig billige Festangestellte, dafür viele teure sog. IT-Berater beschäftigt hatte. Mit den Kunden wurden natürlich teilweise Festpreise vereinbart und teilweise Beratersätze durchgereicht. Die Requirements konnten mehr oder weniger in ein paar algebraischen Gleichungen angegeben werden. Naja, ich hab's schließlich für zehn Stangen Camel programmiert (als hätte ich es damals schon gewusst, denn genau das war wieder zum Ende der .COM-Zeit die Währung, wenn der Insiderhandel herausgekommen ist). Die Entitäten eines Projektabrechnungssystems würde ich heute als weniger überflüssige Daten bezeichnen. Nur um nochmal grob mehr oder weniger unwichtig abzugrenzen.

Zurück zum Key-Store. Aber erst noch einen Ouzo (ich teste gerade den Tsantali Ouzo, nachdem ich den 12er fast schon über habe).

Nochmal. Ich bin darüber gestolpert, weil ich die absolut bescheuerte Idee realisiert habe, in einer Datenbank neben dem Pflegen eines HEAD, einer kompletten Versionshistorie auch noch Tags und Branches anzubieten. Und ja, es funktioniert wirklich, wenn man mit der Wirklichkeit einen eigenartigen Vertrag abgeschlossen hat.
Als ich es im Fieberwahn für angebracht hielt, dass man auch etwas Cherry-Picking mit den Daten betreiben können sollte, bin ich zur Tanke und hab' die neue Flasche Ouzo gekauft, ganz viel Source-Code gelöscht und die Hände hochgelegt. Denn schnell können die Datenbank-Abfragen einfach nicht sein. Tags brauche ich - das Requirement habe ich fix definiert. Außerdem muss ich so einen getaggten Snapshot an einem bestimmten Zeitpunkt veröffentlichen (ist eine wissenschaftliche Datenbank). Wieso kann das nicht schnell sein? Ganz einfach: Wenn ich zu jedem Datensatz k Revisionen in n Tabellen habe und m Joins darauf machen muss - wird's es fies wenn ich nur einen der Parameter anhebe: Ein Produkt eben. Error by Design. Ganz klar. Wobei, ich es mit Merge-Tabellen zumindest soweit schnell bekommen habe, dass ich mit Produktiv-Daten einigermaßen zügig arbeiten konnte. Um das Abfrageverhalten zu verbessern dachte ich natürlich darüber nach, dass ich ja noch nichts gecacht habe - Ich muss schließlich nicht jede Tabelle immer in allen Revisionen online zusammenstellen. Und mit SSilk habe ich auch noch nicht diskutiert. Dafür braucht man aber Zeit. Viel davon, sogar.

Und jetzt sind wir genau da, wo ich mich betrinken muss: Ich muss cachen! Also nochmal speichern. Aber nicht ganz so dauerhaft wie ich es mit den schön geordneten Daten getan habe - sondern so, dass ich ohne viel Arbeit direkt an alles heran komme. Und dazu verwende ich genau die gleichen Schlüssel, die ich brauche, wenn ich direkt auf die Datenbank gehen muss...

Nach einem Ouzo sind mir dann zu meiner tiefsten Frustration folgende Zeilen aus der Zend Framework-Doku entgegen gesprungen:


// We create an instance of Zend_Cache
// (of course, the two last arguments are optional)
$cache = Zend_Cache::factory(
    $frontendName,
    $backendName,
    $frontendOptions,
    $backendOptions
);


Und da ist mir klar geworden, wo das eigentliche Problem ist: Nein, es ist nicht gut, dauerhafte "Bewährtes" immer wieder zu penetrieren. Manche Rezepte für manche Probleme sind schlicht und ergreifend unkorrekt, unvorteilhaft oder schlichtweg falsch. Nur wir können eben das Falsche manchmal so gut, dass wir uns nicht umstimmen lassen wollen.

Da wird eine Factory-Methode angeboten - großes Kino - aber auf der anderen Seite parametrisiere ich den Cache (wie auch anders) mit String-Werten... Also entweder ich mache es objektorientiert und halte auch die Komplexität geringer (ok, ich hätte eben ein paar Objekte mehr - aber die lassen sich viel besser testen. Hachja, Locke, ich pflichte dir zum Thema Object-Injection zu 100% bei, oder ich mache es praktisch wie in den 60ern den lezten Jahrtausends, nach dem KISS-Prinzip. Wir wir alten Männer neuerlich wissen, steht KISS für Keep it Simple: Suicide. Ziemlich stupid. Aber das ist wieder eine andere, kleine Geschichte, die ich irgendwann mal vor dem Schlafen gehen berichten werde, Johnboy.

Ich hab' jetzt genug Alkohol im Blut um Zend Framework zu ertragen. Allerdings muss ich sagen, es hat Spass gemacht, mal die Zend_Application-Komponenten in einem frischen Projekt zu verwenden (wenn gleich ich an manchen Stellen fast verzweifelt bin - aber wie immer im Zend Framework: Es gibt immer mindestens drei Wege eine Aufgabe zu erledigen... und immer mindestens 3 Wege unterschiedliche Fehler zu machen


Weitermachen.