Multi Update: Mehrere Datensätze einer Tabelle haben sich geändert und sollen aktualisiert werden. Anstatt nun jede Menge einzelne Queries zu schreiben gibts es nun zwei Methoden dies möglichst schnell ablaufen zu lassen.

1. Die CASE Methode

UPDATE test

SET bla = CASE id

WHEN 1 THEN ‘flubb’

WHEN 2 THEN ‘blubb’

END

WHERE id IN (1,2)

Innerhalb eines einzigen Querys werden mehrere Einträge verändert.

2. Die PREPARED Methode

Zuerst wie gewünscht eine kleine Einführung in mysqli bzw. meine Datenbankabstraktion:

Link (englisch) Wer mysqli oder PDO noch nicht kennt sollte sich umbedingt informieren!

$stmt = $db->prepare(‘UPDATE test SET bla = ? WHERE id = ?, ‘sd’);

$stmt->execute(array(‘flubb’, 5));

$stmt->execute(array(‘blubb’, 13));

Ein Query wird mit Platzhaltern gefüllt und mehrmals ausgeführt.

Performancevergleich

Ich habe das nun mit zwei Einträgen getestet und 100 bis 10000 Einträge verändert.

Interessantes:

• CASE  skaliert sehr schlecht, bei mehr Arbeit braucht das Query vergleichsweise viel länger
• Mein MySQL Client meldet sich ab, wenn ich 10000 Einträge mit CASE updaten will
• PREPARED skaliert sehr gut, bei doppelter Anzahl Einträge brauchen die Queries doppelt so lange
• Bei unter 1000 Einträgen ist CASE schneller als PREPARED
• Für 10000 Einträge braucht PREPARED weniger lange als CASE für 5000

Schlussfolgerung:

CASE und PREPARED haben verschiedene Vor- und Nachteile. Für wenige Einträge (<1000 Felder upzudaten) bietet sich CASE an. Für große Datenmengen sollte PREPARED verwendet werden.

Ich werde CASE verwenden, zumal ich schon den nötigen Code geschrieben habe um automatisch Queries zu erzeugen.

** Anmerkung: Die Tests wurden auf meinem Laptop (C2D 2×2,4Ghz, 2GB RAM) ausgeführt und sind nur subjektiv. Ich denke dennoch, dass die Ergebnisse auf anderen Systemen durchaus ähnlich ausfallen werden.

Die letzten Tage bin ich aber endlich darauf gekommen, wofür man diese Interfaces in PHP verwenden kann.

Zuerst einmal: Was ist so ein Interface?

Interfaces sind Klassen, die bestimmte Funktionen vorbestimmen. Die Funktionen bilden dann eine Schnittstelle, also eine bestimmte Möglichkeit von anderen Objekten angesprochen zu werden. Im Gegensatz zu anderen Klassen werden Schnittstellen implementiert (“implements”). Dadurch kann eine Klasse mehrere Schnittstellen haben, aber nur von einer einzigen normalen Klasse abstammen.

Man muss also nur die Schnittstelle kennen, um die Klasse verwenden zu können, die sie implementiert. Anders gesagt, man kann die Klasse so verwenden wie man die Schnittstelle als Klasse verwenden würde.

Sehr konkrete Beispiele liefert PHP selbst mit einigen Schnittstellen:

ArrayAcces: Die Objekte einer Klasse lassen sich wie Arrays ansprechen.
Iterator: Die Eigentschaften einer Objekts lassen sich iterieren, also auf eine bestimmte Weise durchlaufen.

Interfaces lassen sich aber auch noch weit abstrakter verwenden:

Ich schreibe ein Interface Datenbankverbindung, das ich aus praktischen Gründen dokumentiere. Ich weise nochmal darauf hin, dass dieses Interfaces keinen Programmcode enthält, es gibt nur Struktur vor.

Danach schreibe ich einen Dekorierer für meine mysqli Klasse und achte derweil auch etwas darauf, wie PDO aufgebaut ist, denn wahrscheinlich wird das eine weitere mögliche Datenbankverbindung (->Interfacename…) mysqli wird etwas zurechtgebogen und erweitert.

Resultat: Ich kann verschiedene Datenbankklassen nach ein paar Anpassungen verwenden. Ich benutze mysqli, weil es anscheinend die schnellste ist, was MySQL angeht. Letztlich verwende ich Typehints auf “Datanbankverbindung” und Autovervollständigung für das Interface, welches ich dokumentiert (phpDoc, Zend Studio) habe.

Ich hoffe, ich habe es etwas anschaulicher erklärt, als es das Handbuch tut. Ich erinnere nocheinmal daran, dass dies keineswegs einfach ist und ich selbst lange gebraucht habe es zu verstehen.

Meiner Meinung nach eine geniale Erfindung, weil sie mit ein wenig MySQL Kenntnissen Cronjobs ersetzen kann. Die anstehenden Änderungen müssen zwar vollständig innerhalb des MySQL und damit in der Datenbank ablaufen, sind dafür aber deutlich flexibler und verlässlicher als Cronjobs. Für mich ist die Handhabung sogar einfacher.

Diese Events eignen sich auch um einen Daemon auf MySQL Basis zu schreiben, der sehr datenbanknah arbeitet. Events werden dadurch in Echtzeit ausgeführt, anstatt, wie beim klassischen Eventhandler, bei jedem Aufruf durchgeführt und zurückberechnet. Das macht einiges deutlich einfacher.