phpbar.de logo

Mailinglisten-Archive

[php] MySQL Datensatzzeiger

[php] MySQL Datensatzzeiger

Yannik Hampe yannik at cipher-code.de
Son Jun 8 00:26:54 CEST 2008


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