![]() Mailinglisten-Archive |
Dr. Volker G�bbels wrote: > Ahoi ;) > >> Wenn du oft in den Datens�tzen bl�ttern musst, empfehle ich dir, die >> ganze Ergebnismenge zuerst in ein array zu kopieren, z. B. mit >> array_push. Doofe Idee, denn es gibt auch den Operator [], der das gleiche macht, nur schneller ist :-P. >> >> http://www.php.net/manual/de/function.mysql-fetch-array.php#76598 > > *�rgs* Aber nur, wenn die maximal m�gliche Datenmenge 1000 Records > (oder so) nicht �berschreitet ;) > Wir haben hier einen Kunden, der Tabellen mit 1-50 Mio. Datens�tzen > hat. Ein "select *" w�re da der Server Tod ;) > Ich gebe aber zu, da� ich, wenn ich genau kontrollieren kann, wieviele > Datens�tze da geflogen kommen, sehr gern zum Beispiel auf ADOdb's > getAll() zur�ck greife ;o) Du bist dir aber schon im klaren, das php's mysql_*-Funktion oer Standardkonfig alles erstmal cachen, was von mysql zur�ckkommt und du mit mysql_fetch_* nur �ber php's cache l�ufst? Naturlich funktioniert die seek-Funktion auch nichtmehr, wenn man diesen cache nicht verwendet (mysql_unbuffered_query()). Es sollte allerdings auch nicht normal sein, dass man einfach mal select * auf eine Datenbank mit 50M Eintr�gen laufen l�sst. Was will man den mit dem result machen? Wenn es sich nicht gerade um ein backupscript oder sowas handelt erscheint mir das grunds�tzlich nicht so schlau. > > Wenn ich einen Algorithmus sehe, der essentiell darauf angewiesen ist, > den "davor stehenden" Datensatz zu lesen, w�rde ich erst mal davon > ausgehen, da� der Algorithmus anders gebaut werden mu�. Jo, das denke ich allerdings auch. Vielleicht solltest du, Reinhold, mal dein Problem schildern, warum du �berhaupt auf diese Funktion angewiesen bist... > > Viele Gr��e, > Volker G�bbels Yannik
php::bar PHP Wiki - Listenarchive