Ich denke mir den Spaß als Rails-Engine, welche die Grundfunktionalität von Active-Record nutzt, ohne aber mit Models zu arbeiten. Keine Validierung, keine Callbacks. Nur direkte Datenbankmanipulation.

Ausgehend von der ActiveRecord::Base.connection kann man direkt die mit Rails verbundene Datenbank ansprechen. Es lässt sich beliebiges SQL ausführen oder man kann diverse High-Level-Methoden der API nutzen.

Der Weg von der Datenbank in das CSV-Format sollte mit Rails vergleichsweise einfach sein. Interessanter erscheint mir das anschließende Update: Machen hier verschiedene Datentypen Probleme? Wie findet man den korrekten Datensatz bei mehrspaltigen Primärschlüsseln?

Data-Warehouse: Datenintegration und -separation

Ein Data-Warehouse ist eine Datenbank, die zwei grundlegende Ziele verfolgt:

1. Datenintegration aus heterogenen Quellen
2. Separation der Daten; das Data-Warehouse hat keinen Einfluss auf die operativen Daten

Datenintegration

Beide Aspekte sind für Website-Statistiken höchst relevant. Viele Web-Server stellen mehrere Websites mit unterschiedlichen Technologien bereit. Selbst wenn nicht, möchte ich als Admin die Möglichkeit haben, meinen Apache gegen ein Nginx oder mein Typo 3 gegen ein WordPress auszutauschen. Heterogene Quellen, in welchen die Daten auflaufen, sind somit zumindest potentiell immer gegeben. Ein weiterer Vorteil: Bin ich auf kein festes Format angewiesen, kann ich auch immer die nativen Mechanismen der verwendeten Software nutzen. Apache, Nginx und Co. loggen ohnehin jeden Besucher mit, eine zusätzliche Erfassung der Daten (wie zum Beispiel durch Piwik) ist oft gar nicht nötig. Ein Data-Warehouse kann diese selbstständig integrieren.

Datenseparation

Auch Punkt 2 ist wie fürs Web gemacht: Statistiken sind sicher wichtig, aber nie so, dass sie das eigentliche Webangebot behindern dürften. Ist der Server bereits ausgelastet, so kann ein Aufruf der Statistiken mit unzähligen Leseoperationen und Berechnungen zum großen Problem werden. Spätestes wenn der Speicher voll ist gehen bei kleinen Projekten wie diesem Blog die Lichter aus. Das Prinzip der Datenseparation bietet hier Abhilfe: Die Statistiken werden vollständig von den operativen Daten getrennt. Das Data-Warehouse kann bei Bedarf auf einem anderen Server liegen.

Hierfür müssen die operativen Daten zwar ebenfalls gelesen werden, dies kann in hohen Lastphasen aber einfach unterbunden werden. Der Webserver kann sich auf seinen eigentlichen Job konzentrieren und auch der Statistikaufrufer kriegt schnell und optimiert seine Zahlen. Lediglich Letzterer hat hierbei den Nachteil, dass die Daten nicht mehr ganz in Echtzeit bereitstehen – was wohl zu verkraften sein dürfte. Das Internet ist zwar schnelllebig, die Zugriffe von vor fünf Minuten sind für die meisten aber aktuell genug.

Nachteile

Der Data-Warehouse-Ansatz für die Website-Zugriffsanalyse birgt kaum Probleme. Zwei drängen sich zunächst auf:

• Keine Echtzeitdaten
• Erhöhter Speicherverbrauch durch Datenduplizierung

In meinen Augen sind beide Nachteile unkritisch. Die Aktualitätsspanne zwischen Echtzeit- und Data-Warehouse-Daten lässt sich je nach Kapazität beliebig verkleinern. Je öfter die Daten integriert werden, desto weniger Neuerungen sind zu verarbeiten. Selbst minütliche Syncs sind realistisch, wenn man seine Zugriffsspitzen im Blick hat und nach Bedarf das Intervall anpasst.

Der vermehrte Speicherverbrauch war selbst zu Zeiten der Festplattenkrise kein Problem. Wer jeden Tag gigabyteweise Zugriffsdaten wegschreibt hat sicher andere Sorgen als zehn Festplatten im Jahr…

Skalierbarkeit und Datenstrukturkonzeption

Das Konzept Data-Warehouse ist simpel und überzeugend. Für Website-Statistiken überzeugt vor allem die Skalierbarkeit: Vom kleinen PHP-Webspace mit My-SQL-Datenbank kann eine gut konzipierte Datensammlung mitwachsen und auf beliebig große und verteilte Systeme migriert werden.

Zudem bietet dieses Forschungsfeld interessante Ansätze, wie man Daten effizient an das Anwendungsfeld angepasst strukturiert. OLAP-Cubes und Sternschemas für relationale Datenbanken sind wichtige Stichwörter, die jedoch einen eigenen Artikel rechtfertigen.

Transaktionen in PostgreSQL

begin;
alter table mytable rename column id to name;
\d mytable

         Table "public.mytable"
   Column   |   Type     |   Modifiers   
------------+------------+--------------
 name       | bigint     | not null

rollback;
\d

         Table "public.mytable"
   Column   |   Type     |   Modifiers   
------------+------------+--------------
 id         | bigint     | not null

Sind die vorgenommenen Änderungen korrekt, können sie mit commit; übernommen werden. Der offizielle SQL-Befehl zum Starten einer Transaktion ist start transaction;. Allerdings unterstützen alle mir bekannten Datenbanken die etwas handlichere Form begin;.

Verschachtelte Transaktionen: Savepoints

Ist der Test komplexer, so dass man Transaktionen schachteln möchte, kann man sogenannte Savepoints verwenden.

begin;
-- Änderung 1
savepoint sp1;
-- Änderung 2a
rollback to savepoint sp1; -- 2a zurücknehmen
-- Änderung 2b
rollback; -- 2b und 1 zurücknehmen

Transaktionen in MySQL

Die PostgreSQL-Beispiele werden auch von MySQL unterstützt.

liquibase.exception.ValidationFailedException: Validation Failed:
1 change sets check sum
changelog.xml::changeSetId::author is now: 3:eeeedcadbc71ae018f46bd682e9132c7

Die Lösung ist recht einfach: Der betroffene Hashwert kann aus der Changelog-Tabelle von Liquibase entfernt werden:

update databasechangelog set md5sum = null where id = 'changeSetId';

Beim nächsten Update wird nun der korrekte Wert nachgetragen, ohne dass die zugehörigen Änderungsanweisungen erneut ausgeführt werden:

Updating null or out of date checksum on changeSet etc/db/changelog.xml::changeSetId::author::(Checksum: 3:...) to correct value

Der Speicherfresser: Array zurückgeben

function getAllTableRows() {
  // ...
  return $allRows;
}
$allRows = getAllTableRows();

Dieser Ansatz führte nun leider regelmäßig dazu, dass PHP mit einer Speicherfehlermeldung abbrach.

Der sparsame Ansatz: Array als Referenzparameter

function getAllTableRows(&$allRows) {
  // alle Werte in $allRows schreiben
}
$allRows = array();
getAllTableRows($allRows);

Fast schon traurig, dass das für PHP so einen Unterschied macht. Ich vermute, dass das an PHPs Eigenheit liegt, mehr auf Werten als auf Referenzen zu arbeiten. Ironischerweise behauptet das PHP-Manual an ähnlicher Stelle, der Kern sei intelligent genug, dies selbst zu optimieren, zumindest was Rückgaben angeht.

Mangels ausreichend großer Beispiel konnte ich den folgenden Ansatz nicht testen:

function &getAllTableRows() {
  // ...
  return $allRows;
}
$allRows =& getAllTableRows();

Das Ziel

Wir möchten eine Liste von Logs im Browser anzeigen. Da Sortierung und Seiteneinteilung von Javascript übernommen werden, möchten wir direkt 1000 Zeilen der Datenbanktabelle in die HTML-Tabelle übertragen. Die Tabelle soll dabei möglichst schnell ausgeliefert werden.

Der Ablaufplan

Nichts zu sehen? Zur PNG-Version.

Hinweis: Die Darstellung ist nicht ganz korrekt, da der Controller die gerenderten Daten des Templates zurückbekommt und diese in Richtung Ausgabe weiterleitet. Vielen Dank an Alex für diesen Hinweis.

Der Controller

Der Controller verliert in diesem Ansatz die Aufgabe, irgendwelche Daten für die Log-Tabelle zu besorgen. Er muss lediglich das entsprechende Template aufrufen und ggf. andere Jobs erledigen, die neben der Tabelle auf der Seite zu sehen sind.

Das Fluid-Template

Das Template gestaltet das Drum-Herum und ruft darin für die Log-Tabelle einen View-Helper auf. Zudem kann man als Inhalt des View-Helper-Tags ein Template vorgeben, in welchem der Helper nur Variablen ersetzen braucht. Hierfür muss man den allgemeinen Teil von dem trennen, der mit jeder Zeile wiederholt werden muss. Ein simpler Ansatz wäre etwa:

	
			

		
ID
Inhalt
		
%1$d
%1$s
		
	

Das obige Variablenformat lässt sich dann direkt mit PHPs Sprintf-Funktion befüllen.

Der View-Helper

Dies ist die einzige Stelle, an der wie die kompletten Log-Daten zwischenspeichern. Dafür aber gleich im fertigen Ausgabeformat, so dass wir sie nicht noch einmal durcharbeiten müssen. Hierfür nehmen wir eine Singleton-Instanz des Iterator-Repositorys, iterieren über die einzelnen Zeilen der Datenbanktabelle und befüllen hiermit jeweils unser Template. Am Ende geben wir den so zusammengebauten Ausgabestring zurück.

Das Iterator-Repository

Das Repository implementiert das PHP-Iterator-Interface. Dies erlaubt es dem View-Helper, das Repository in einer Foreach-Schleife auszulesen. Der Rest ist relativ simpel: Beim Aufruf von rewind() und dem Konstruktor wird ein Query abgesetzt, das Result speichern wir in einem Klassenattribut, um es in anderen Methoden nutzen zu können.

$this->result = $GLOBALS['TYPO3_DB']->SELECTquery(/*...*/);

Hierbei sollte gleich darauf geachtet werden, dass möglichst viel Logik direkt in SQL erledigt wird. So kann man beispielsweise Datumsformate direkt im Query definieren.
Ein Aufruf von next() setzt ein Row-Attribut mittels

$this->row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($this->result);

Zu guter Letzt muss ein current() noch $this->row oder eine angepasste Variante davon zurückgeben.

Fazit

Die vorgegebenen Code-Schnipsel dienen der Verdeutlichung und sind nicht vollständig. Wenn man dem Ansatz jedoch folgt, kann man sehr direkt auf der Datenbank arbeiten, ohne die offizielle Vorgehensweise von Extbase wirklich zu verletzen.