Halihallo Sven
Bedenke nämlich, dass es, im Gegensatz zu Perl, problemlos möglich ist, beide Indextypen in einem Array zu mischen. Allein das kann nur funktionieren, wenn intern kein großer Unterschied gemacht wird (und ich vermute, die numerischen Indices werden einfach zu Strings gemacht).
Ich nehme es so auch an.
Bei der Performance ist es gut möglich, dass der Unterschied nicht messbar ist. Natürlich ist dies noch lange kein Grund auf die selbsterklärenden assoziativen Indexe zu verzichten, da gebe ich dir recht.
Du wirst bei der Abfrage einer Datenbank doch bitte nicht mit Speicherauslastung argumentieren wollen!
Touché! :-)
Da hat ein einzelnes mysql_fetch_assoc oder mysql_fetch_row nämlich den geringsten Anteil dran, denn es wird ja nur ein Datensatz aus dem Abfrageergebnis geholt. Zuvor jedoch werden gewöhnlich _alle_ abgefragten Datensätze in einen Puffer kopiert.
OK, das ist in den meisten Fällen richtig. In Perl zumindest ist mysql_store_result der
default, will heissen, dass das ganze Result-Set in einem wisch auf den Client übertragen
wird und so den Client-Speicher frisst. Jedenfalls unterstützt MySQL auch
mysql_use_result, wo die Daten nur auf Anfrage vom Server übertragen werden und somit
den Speicherverbrauch beim Server liegt (natürlich ist es oft der Fall, dass beide
Systeme auf demselben Rechner liegen). Äm, hm, das ändert eigentlich dennoch nicht viel
an der Sache... ;)
_Das_ kostet im Zweifel den Speicher (und wer je nur einen einzigen Datensatz abfragt, der mehrere Gigabyte Daten ergibt, weil ein ungünstiges BLOB darunter ist, der hat andere Probleme, und insbesondere dann keine _zusätzlichen_ Probleme, weil der Arrayindex zu groß ist).
Wohl wahr...
Viele Grüsse
Philipp
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.