nicht angemeldet
Hi!
Dann iterierst du aber zweimal über die Daten, einmal die Fetch-Schleife um das Rückgabe-Array zu erstellen und dann die Ausgabe-Schleife über dieses Array.
Bei kleinen Array ist das ok. Wenn es absehbar ist, dass ein Result ein bischen größer wird (oder wenn es eben nicht absehbar ist, wie groß das wird, maximal-Grenze festlegen), ist eine Callback-Funktion (CB) angebracht: damit liegt nicht die gesamte Tabelle im Hauptspeicher sondern nur ein Record, während der Iteration innerhalb der DB-Class bringt die CB die Daten sofort auf die Ausgabe.
Um das als nicht wirklich zielführend zu erkennen, muss man die PHP-Interna und die MySQL-Client-API-Arbeitsweise ein wenig kennen. Das Ergebnis einer Query liegt üblicherweise sowieso im Hauptspeicher, weil die MySQL-Client-API selbiges bereits im Hintergrund abholt. Die Fetch-Vorgänge holen die Datensätze nur noch aus diesem Puffer. (Nur bei ungepufferten Querys holt das Fetchen die Daten live ab. Ungepuffert sollte man nur bei großen Datenmengen verwenden, wenn der Roundtrip für jeden Fetch-Vorgang nicht mehr ins Gewicht fällt.) Ab PHP 5.3 mit dem mysqlnd-Treiber wird der Puffer sogar so angelegt, dass das Fetchen in PHP-Variablen keine Kopien der Daten mehr erzeugt sondern die Variablen gleich direkt auf die Pufferstelle verweisen. Das heißt, dass beim Fetchen und Ergebnis-Array-Anlegen nur Variablencontainer für die Verweise auf die gepufferten Daten angelegt werden. Ein Callback bringt keine Vorteile, nur zusätzliche Funktionsaufrufe. Aber selbst mit ungepufferten Daten würde ich keine Callbacks nehmen, sondern würde das Iterator-Interface aus der SPL implementieren. Dann kann der AL in jedem Fall über das Ergebnis der DAL-Funktion mit foreach iterieren - entweder über ein echtes Array oder eben simuliert. Somit muss man im AL nicht beachten, ob man einfach iterieren kann oder callbacken muss.
Lo!