SELECT * und Views...

Hallo,

nachdem ich nun lange genug nur Lurker war, habe ich eine Frage zu der
ich nicht wirklich schlau geworden bin:

Man soll ja nach Möglichkeit kein "SELECT *" benutzen, da es sich
negativ auf die Preformance auswirken kann, die php-faq sagt z.B:

> Bei der SQL-Anweisung SELECT * FROM ... muss das
> Datenbank-Management-System (DBMS) alle Spalten der betreffenden
> Datensätze selektieren, auch wenn in der anschließenden Verarbeitung
> nur ein Teil davon wirklich gebraucht wird. Das ist langsam und
> schlicht und einfach unsinnig, und die unnötigen Spalten verhindern
> unter Umständen, dass der integrierte Optimizer die Query effizient
> ausführen kann.
(http://www.php-faq.de/q/q-sql-select.html)

Nur: Wie sieht es bei Views aus? Ich habe eine View definiert in der
kein * benutzt wurde, sondern alle benötigten Felder einzeln angegeben
wurden (nennen wir es mal 'View_XYZ') - hat nun die Verwendung von
"SELECT * FROM View_XYZ" irgendwelche negativen Auswirkungen auf die
Performance? (Oder gar andere Nachteile die ich übersehe?)

Gibt es dazu eventuell im MySQL-Manual Angaben die ich übersehen habe?

regards,
Jens

Re: SELECT * und Views...

Jens Himmelrath wrote:

> Man soll ja nach Möglichkeit kein "SELECT *" benutzen, da es sich
> negativ auf die Preformance auswirken kann,

IMHO ist das nicht das wichtigste Argument, denn wenn man alle Spalten
braucht, sollte es keinen Performance-Unterschied machen.


>> Bei der SQL-Anweisung SELECT * FROM ... muss das
>> Datenbank-Management-System (DBMS) alle Spalten der betreffenden
>> Datensätze selektieren, auch wenn in der anschließenden Verarbeitung
>> nur ein Teil davon wirklich gebraucht wird.

Denn genau dann ist ein SELECT * einfach "zuviel".

In dem von Dir geschilderten Fall ist es hingegen so: Du definierst eine
View, die Dir wirklich nur das zurückgibt, was Du brauchst. Dann sollte
ein SELECT * auf diese View zumindest keine Perormance-Unterschiede
machen.


Allerdings gibt es noch einen Grund, weshalb SELECT * "böse" ist: die
Reihenfolge der zurückgegebenen Spalten ist abhängig von ihrer
Definition in der Datenbank, und wenn die sich ändert, kann es Dir u.U.
die Applikation zersäbeln. Dieses Argument trifft genauso natürlich auch
auf Views zu.


Thomas
--
Blödsinnige Liedtexte, Teil 3:
"Erzähle mir, norwegisches Mädchen, wie zu Eingabetaste Deine Welt..."
"Gryy zr, abejrtvny tvey, ubj gb ragre lbhe jbeyq..."

Re: SELECT * und Views...

Thomas Rachel schrieb:
>
> Allerdings gibt es noch einen Grund, weshalb SELECT * "böse" ist: die
> Reihenfolge der zurückgegebenen Spalten ist abhängig von ihrer
> Definition in der Datenbank, und wenn die sich ändert, kann es Dir u.U.
> die Applikation zersäbeln. Dieses Argument trifft genauso natürlich auch
> auf Views zu.

Wahrscheinlich werden wir jetzt zu OT, da es sich um kein MySQL-Problem
mehr handelt, aber:
Sollte mich das kümmern, wenn ich auf die Spalten über Ihren Namen zugreife?
Hat es einen Vorteil über die Reihenfolge zuzugreifen?

Und um nochmal aus dem OT zu geraten: Man kann doch innerhalb von
SQL-Statements bzw. Procedures immer über den Namen zugreifen, oder gibt
es hier eine Möglichkeit in der ich die Reihenfolge benötige?

regards,
Jens

Re: SELECT * und Views...

Hi Jens

Jens Himmelrath wrote:
> Thomas Rachel schrieb:
>> Allerdings gibt es noch einen Grund, weshalb SELECT * "böse" ist: die
>> Reihenfolge der zurückgegebenen Spalten ist abhängig von ihrer
>> Definition in der Datenbank, und wenn die sich ändert, kann es Dir u.U.
>> die Applikation zersäbeln. Dieses Argument trifft genauso natürlich auch
>> auf Views zu.
> Wahrscheinlich werden wir jetzt zu OT, da es sich um kein MySQL-Problem
> mehr handelt, aber:
> Sollte mich das kümmern, wenn ich auf die Spalten über Ihren Namen
> zugreife?
> Hat es einen Vorteil über die Reihenfolge zuzugreifen?
> Und um nochmal aus dem OT zu geraten: Man kann doch innerhalb von
> SQL-Statements bzw. Procedures immer über den Namen zugreifen, oder gibt
> es hier eine Möglichkeit in der ich die Reihenfolge benötige?

Meist wird ja die DB auch von ausserhalb bedient und der zitierste
Artikel entstammt der PHP-FAQ... MySQL-internes intressiert da wenig,
sondern eigentlich mehr solche Konstrukte:

echo "";
$sql = "select * from tabelle";
$result = mysql_query($sql);
while (list($dbid,$dbname) = mysql_fetch_row($result))
echo "dbname\n";
echo "";

Da sieht man doch auf den ersten Blick, dass * zu verwenden böse ist.
HTH, Johannes

Re: SELECT * und Views...

Johannes Vogel wrote:
> Meist wird ja die DB auch von ausserhalb bedient und der zitierste
> Artikel entstammt der PHP-FAQ... MySQL-internes intressiert da wenig,
> sondern eigentlich mehr solche Konstrukte:
> echo "";
> $sql =3D "select * from tabelle";
> $result =3D mysql_query($sql);
> while (list($dbid,$dbname) =3D mysql_fetch_row($result))
> echo "dbname\n";
> echo "";
> Da sieht man doch auf den ersten Blick, dass * zu verwenden böse is=
t.

Ich sehe da eher, dass man auf Dollar-Zeichen achten sollte und dass
man Datenbank-Inhalte nicht ungequoted in HTML stopfen sollte (so,
wie man vom Client empfangene Daten auch nicht ungequoted in
HTML-Statements packt). Aber was soll man von einer PHP-FAQ erwarten?

[OT] SELECT * und Weiterverarbeitung in PHP (Was: Re: SELECT * undViews...)

Johannes Vogel schrieb:
> Hi Jens
>
>> [Frage nach den genauen Nachteilen von "SELECT *"]
>
> Meist wird ja die DB auch von ausserhalb bedient und der zitierste
> Artikel entstammt der PHP-FAQ... MySQL-internes intressiert da wenig,
> sondern eigentlich mehr solche Konstrukte:
>
> echo "";
> $sql = "select * from tabelle";
> $result = mysql_query($sql);
> while (list($dbid,$dbname) = mysql_fetch_row($result))
> echo "dbname\n";
> echo "";

Wenn ich das richtig sehe ist das Problem genau nur dann eines, wenn die
Änderung an der Datenbank zwischen Generierung der Seite und Abschicken
des Formulars geschieht?
Gleichzeitig würde dieses Problem dann nicht mehr auftreten, wenn man
das mysql_fetch_row durch ein mysql_fetch_assoc ersetzen würde.
Oder übersehe ich was?

> Da sieht man doch auf den ersten Blick, dass * zu verwenden böse ist.

Ich ehrlich gesagt noch nicht wirklich, denn das Problem kann man ja
umgehen (nagut, schön ist es nicht und eine Gefahrenquelle), indem man
Updates an der Datenbank immer nur dann vornimmt, wenn der Zugriff auf
den Server gesperrt ist (natürlich dürften danach keine Daten von alten
Anfragen mehr angenommen werden - es kompliziert also die Entwicklung
der Eingabeüberprüfung unnötig).

regards,
Jens
PS: Wird so langsam ein F'up2 de.comp.lang.php.datenbanken notwendig?

Re: SELECT * und Views...

On 10 Sep 2006 08:53:09 GMT, Sven Paulus wrote:

> Johannes Vogel wrote:
>> Meist wird ja die DB auch von ausserhalb bedient und der zitierste
>> Artikel entstammt der PHP-FAQ... MySQL-internes intressiert da wenig,
>> sondern eigentlich mehr solche Konstrukte:
>> echo "";
>> $sql = "select * from tabelle";
>> $result = mysql_query($sql);
>> while (list($dbid,$dbname) = mysql_fetch_row($result))
>> echo "dbname\n";
>> echo "";
>> Da sieht man doch auf den ersten Blick, dass * zu verwenden böse ist.
>
> Ich sehe da eher, dass man auf Dollar-Zeichen achten sollte und dass
> man Datenbank-Inhalte nicht ungequoted in HTML stopfen sollte (so,
> wie man vom Client empfangene Daten auch nicht ungequoted in
> HTML-Statements packt). Aber was soll man von einer PHP-FAQ erwarten?

Zeig mir unter dem vom Originalposter erwähnten Link in der PHP-FAQ
(http://www.php-faq.de/q/q-sql-select.html), wo du dort Probleme siehst.

Du hast den Artikel in der FAQ ganz offensichtlich nicht gelesen und fühlst
dich trotzdem dazu bemüßigt hier die PHP-FAQ niederzumachen.

Wir brauchen wohl kaum darüber zu diskutieren, dass PHP eine reichlich
krude Sprache mit einigen Ecken und Kanten ist. Aus diesem Grunde aber
geistlos auf die Autoren der PHP-FAQ einzudreschen weil PHP-Bashing dir
hier angebracht scheint und du dir begeisterten Zuspruch der Mitleser
erwartest ist schlicht und einfach niveaulos.

Matthias

Re: SELECT * und Views...

Jens Himmelrath schrieb:

> Thomas Rachel schrieb:
>
>> Allerdings gibt es noch einen Grund, weshalb SELECT * "böse" ist: die
>> Reihenfolge der zurückgegebenen Spalten ist abhängig von ihrer
>> Definition in der Datenbank, und wenn die sich ändert, kann es Dir u.U.
>> die Applikation zersäbeln. Dieses Argument trifft genauso natürlich auch
>> auf Views zu.
>
> Sollte mich das kümmern, wenn ich auf die Spalten über Ihren Namen zugreife?

In diesem Fall ist die tatsächliche Reihenfolge in der Tabelle natürlich
vollkommen egal und braucht Dich deshalb auch nicht zu jucken.

> Und um nochmal aus dem OT zu geraten: Man kann doch innerhalb von
> SQL-Statements bzw. Procedures immer über den Namen zugreifen, oder gibt
> es hier eine Möglichkeit in der ich die Reihenfolge benötige?

Ja, die kann es z.B. dann geben, wenn man immer alle Feldelemente braucht.

Ein aktuelles Beispiel aus meiner Praxis: Ich habe für einen Kunden
einen Maskengenerator in PHP erzeugt, der aus einer Tabelle automatisch
eine passende Eingabemaske erzeugt. Hierbei wird für jedes Feld eine
Zeile mit Feldname und dem Eingabefeld erzeugt, und zwar genau in der
Reihenfolge, in der die Spalten in der Tabelle liegen. Änderungen an der
Tabelle zeigen sich folglich auch sofort in der Maske, ohne dass ich am
Programm irgendetwas ändern müsste.

Bestimmte zusammengehörende Feldpaare (z.B. PLZ und Ort, Straße und
Hausnummer, Vor- und Nachname) werden jedoch in einer gemeinsamen
Maskenzeile darstellt. Hierbei verlasse ich mich darauf, dass diese auch
direkt hintereinander und in der richtigen Reihenfolge in der Tabelle
stehen. Wenn sich also die Tabellenstruktur ändert, muss ich darauf
achten, dass diese Reihenfolge erhalten bleibt. Sonst zerbröselt es mir
die Maske.

Gruß. Claus

Re: SELECT * und Views...

Hi

Claus Reibenstein schrieb:
> =

> Jens Himmelrath schrieb:
> =

> > Thomas Rachel schrieb:
> >
> >> Allerdings gibt es noch einen Grund, weshalb SELECT * "böse" is=
t: die
> >> Reihenfolge der zurückgegebenen Spalten ist abhängig von i=
hrer

[...]

> Zeile mit Feldname und dem Eingabefeld erzeugt, und zwar genau in der
> Reihenfolge, in der die Spalten in der Tabelle liegen. Änderungen =
an der
> Tabelle zeigen sich folglich auch sofort in der Maske, ohne dass ich am=

> Programm irgendetwas ändern müsste.
> =

> Bestimmte zusammengehörende Feldpaare (z.B. PLZ und Ort, Straß=
e und
> Hausnummer, Vor- und Nachname) werden jedoch in einer gemeinsamen
> Maskenzeile darstellt. Hierbei verlasse ich mich darauf, dass diese auc=
h

[...]

Dies sind dann die Probleme, die man oft ewig sucht.
Man sollte sich nicht auf die Reihenfolge der Spalten
verlassen, auch nicht in deinem Fall.
Denn jede kleinste Anpassung kann dann zum
SuperGau führen.

gruß n.Olivier
-- =

Nachbagauer Olivier - www.nOlivier.com
www.reedb.com - Immobilien nationale & international =

Webportal der Immobilien-Branche - www.Immofinder.de

Re: SELECT * und Views...

Jens Himmelrath wrote:
> Thomas Rachel schrieb:
>>
>> Allerdings gibt es noch einen Grund, weshalb SELECT * "böse" ist: die
>> Reihenfolge der zurückgegebenen Spalten ist abhängig von ihrer
>> Definition in der Datenbank, und wenn die sich ändert, kann es Dir u.U.
>> die Applikation zersäbeln. Dieses Argument trifft genauso natürlich auch
>> auf Views zu.

Es ist nicht nur die Reihenfolge. Es können auch Spalten hinzukommen
oder verschwinden. Wenn ein BLOB hinzukommt, den besagte Query nicht
braucht, zieht das Performance-Argument. Wenn eine Spalte verschwindet
oder umbenannt wird, funktioniert SELECT * unbeeindruckt, aber kann
auch die Applikation damit umgehen?

> Wahrscheinlich werden wir jetzt zu OT, da es sich um kein MySQL-Problem
> mehr handelt, aber:
> Sollte mich das kümmern, wenn ich auf die Spalten über Ihren Namen zugreife?
> Hat es einen Vorteil über die Reihenfolge zuzugreifen?

Aus manchen Programmiersprechen (z.B. C) kann man gar nicht über die
Namen zugreifen (bzw. es ist sinnlos aufwendig). In anderen Sprachen
ist der Zugriff über die Reihenfolge u.U. viel einfacher. Z.B.


$sth= $dbh->prepare("SELECT id, name, created FROM customer");
$sth->execute();
while (($id, $name, $datum)= $sth->fetchrow_array()) {

}


ist viel schöner als


$sth= $dbh->prepare("SELECT id, name, created FROM customer");
$sth->execute();
while ($res= $sth->fetchrow_hashref()) {
$id= $res->{"id"};
$name= $res->{"name"};
$datum= $res->{"created"};
}


PHP wird beim Zugriff auf eine nichtexistierende Spalte u.U. keine
Fehlermeldung ausspucken (in einer Produktivumgebung stellt man das
Warninglevel i.d.R. sehr niedrig, damit der Anwender keine PHP-Fehler-
Meldungen zu sehen bekommt) sondern einfach "undefined" liefern.

Hand aufs Herz, würden alle deine Programme eine sinnvolle Fehlermeldung
liefern, wenn eine Spalte umbenannt wurde und deswegen nach SELECT *
nicht mehr im Ergebnis gefunden wird?

> Und um nochmal aus dem OT zu geraten: Man kann doch innerhalb von
> SQL-Statements bzw. Procedures immer über den Namen zugreifen, oder gibt
> es hier eine Möglichkeit in der ich die Reihenfolge benötige?

Man greift eigentlich *immer* über den Namen zu. Die Reihenfolge der
Spalten "in der Tabelle" ist bis auf wenige Ausnahmen bedeutungslos.

Ich kann auch das Argument "SELECT * ist weniger Schreibarbeit" nicht
nachvollziehen. Wenn ich zum Bearbeiten des Ergebnisses sowieso jede
Spalte mit Namen nennen muß, dann kann ich die Spaltennamen auch gleich
ins SELECT schreiben. Eher ist es mir umgekehrt weniger Arbeit, die
Spalten im SELECT aufzuführen und dann das Ergebnis als Array zu
behandeln.


XL

Re: SELECT * und Views...

Axel Schwenke schrieb:
> Jens Himmelrath wrote:
>> Thomas Rachel schrieb:
>>> Allerdings gibt es noch einen Grund, weshalb SELECT * "böse" ist: die
>>> Reihenfolge der zurückgegebenen Spalten ist abhängig von ihrer
>>> Definition in der Datenbank, und wenn die sich ändert, kann es Dir u.U.
>>> die Applikation zersäbeln. Dieses Argument trifft genauso natürlich auch
>>> auf Views zu.
>
> Es ist nicht nur die Reihenfolge. Es können auch Spalten hinzukommen
> oder verschwinden. Wenn ein BLOB hinzukommt, den besagte Query nicht
> braucht, zieht das Performance-Argument. Wenn eine Spalte verschwindet
> oder umbenannt wird, funktioniert SELECT * unbeeindruckt, aber kann
> auch die Applikation damit umgehen?

Aber das trifft doch zumindest nicht bei Benutzung einer festen View zu,
oder?

>
>> Wahrscheinlich werden wir jetzt zu OT, da es sich um kein MySQL-Problem
>> mehr handelt, aber:
>> Sollte mich das kümmern, wenn ich auf die Spalten über Ihren Namen zugreife?
>> Hat es einen Vorteil über die Reihenfolge zuzugreifen?
>
> Aus manchen Programmiersprechen (z.B. C) kann man gar nicht über die
> Namen zugreifen (bzw. es ist sinnlos aufwendig).

Das bedeutet, da PHP in C geschrieben ist, setzt der bei Benutzung von
mysql_fetch_assoc zwangsweise immer noch ein "SHOW COLUMNS" ab?

> In anderen Sprachen
> ist der Zugriff über die Reihenfolge u.U. viel einfacher. Z.B.
>
> [snip]
> while (($id, $name, $datum)= $sth->fetchrow_array()) {
> [snip]
> ist viel schöner als
> [snip]
> while ($res= $sth->fetchrow_hashref()) {
> $id= $res->{"id"};
> $name= $res->{"name"};
> $datum= $res->{"created"};
> }

Gibt's in PHP auch: list($a, $b, $c) = mysql_fetch_row($res)
Dennoch: Das erste was man mir sagte: "Tu dir 'nen Gefallen, greif immer
über den Spaltennamen zu."
Und mal ganz ehrlich es ist vor allem kürzer, über schöner lässt sich
streiten - und je kürzer desto weniger offensichtlich für nachfolgende
Leser (nagut, in diesem trivialen Fall vielleicht eher nebensächlich).

> PHP wird beim Zugriff auf eine nichtexistierende Spalte u.U. keine
> Fehlermeldung ausspucken (in einer Produktivumgebung stellt man das
> Warninglevel i.d.R. sehr niedrig, damit der Anwender keine PHP-Fehler-
> Meldungen zu sehen bekommt) sondern einfach "undefined" liefern.
>
> Hand aufs Herz, würden alle deine Programme eine sinnvolle Fehlermeldung
> liefern, wenn eine Spalte umbenannt wurde und deswegen nach SELECT *
> nicht mehr im Ergebnis gefunden wird?

Deswegen nutze ich ja normalerweise kein *.
Ich muss gleich mal ausprobieren, was mit meiner View passiert, wenn ich
versuche einen Spaltennamen umzubenennen auf den sie abfragt...

>> Und um nochmal aus dem OT zu geraten: Man kann doch innerhalb von
>> SQL-Statements bzw. Procedures immer über den Namen zugreifen, oder gibt
>> es hier eine Möglichkeit in der ich die Reihenfolge benötige?
>
> Man greift eigentlich *immer* über den Namen zu. Die Reihenfolge der
> Spalten "in der Tabelle" ist bis auf wenige Ausnahmen bedeutungslos.
>
> Ich kann auch das Argument "SELECT * ist weniger Schreibarbeit" nicht
> nachvollziehen. Wenn ich zum Bearbeiten des Ergebnisses sowieso jede
> Spalte mit Namen nennen muß, dann kann ich die Spaltennamen auch gleich
> ins SELECT schreiben. Eher ist es mir umgekehrt weniger Arbeit, die
> Spalten im SELECT aufzuführen und dann das Ergebnis als Array zu
> behandeln.

Full Ack.
Eigentlich ist es mir persönlich auch egal mehr zu schreiben - erhöht
nur die Lesbarkeit des Codes, allerdings wollte ich über eine View
versuchen den Code noch portabler zu machen: Wenn sich was an der
DB-Struktur ändern sollte, muss ich nur die View ändern und nicht im
Code nach SQL-Statements suchen. Ich weiß, die DB sollte sich nicht
ändern, dafür macht man ja vorher ein gescheites Design - aber gerade
bei kleineren Projekten die plötzlich dann doch das doppelte können
sollen passt das Konzept ganz schnell nicht mehr auf des ursprüngliche
Design.

Die Frage nach der Performance und den Nachteilen eines "SELECT *" war
eigentlich eine reine Interessenfrage weil mir einfach spontan kein
wirklicher Nachteil einfallen wollte, bzw. alle "SELECT *"-Nachteile auf
eine View mit festen Spaltennamen nicht passen wollten.

regards,
Jens
PS: Liegen die komischen Sonderzeichen im zitierten Text an meinen
Einstellungen?

Re: SELECT * und Views...

Jens Himmelrath wrote:


>> Aus manchen Programmiersprechen (z.B. C) kann man gar nicht über die
>> Namen zugreifen (bzw. es ist sinnlos aufwendig).
>
> Das bedeutet, da PHP in C geschrieben ist, setzt der bei Benutzung von
> mysql_fetch_assoc zwangsweise immer noch ein "SHOW COLUMNS" ab?

Nein. Es gibt in der C-API Funktionen, mit denen sich auf
Spalteninformationen wie Typ, Länge und eben auch Name zugreifen läßt.
Es geht in C, aber es erfordert eben einige Umstände, das tatsächlich so
zu machen. Zu diesem Thema gab es vor kurzem auch einen Thread hier.


>> In anderen Sprachen
>> ist der Zugriff über die Reihenfolge u.U. viel einfacher. Z.B.
>>
>> [snip]
>> while (($id, $name, $datum)= $sth->fetchrow_array()) {
> > [snip]
>> ist viel schöner als
>> [snip]
>> while ($res= $sth->fetchrow_hashref()) {
>> $id= $res->{"id"};
>> $name= $res->{"name"};
>> $datum= $res->{"created"};
>> }

Das kommt IMHO ganz darauf an, ob man das Ergebnis "direkt" verarbeiten
will, oder ob man es u. U. einer Funktion o. ä. übergeben will.


> ..., allerdings wollte ich über eine View
> versuchen den Code noch portabler zu machen: Wenn sich was an der
> DB-Struktur ändern sollte, muss ich nur die View ändern und nicht im
> Code nach SQL-Statements suchen. Ich weiß, die DB sollte sich nicht
> ändern, dafür macht man ja vorher ein gescheites Design - aber gerade
> bei kleineren Projekten die plötzlich dann doch das doppelte können
> sollen passt das Konzept ganz schnell nicht mehr auf des ursprüngliche
> Design.

ACK. Das kenne ich - irgendwann gibt es immer eine Änderung, und wenn man
Pech hat und das Programm zuwenig strukturiert hat, zieht sie einen
Rattenschwanz an Änderungen nach sich.


> PS: Liegen die komischen Sonderzeichen im zitierten Text an meinen
> Einstellungen?

Nein, das war Axel. :-}


Thomas
--
Meine Meinung ist Public Domain.
Jeder darf sie sich zu eigen machen.

Re: SELECT * und Views...

Jens Himmelrath wrote:
> Axel Schwenke schrieb:
>>
>> Es ist nicht nur die Reihenfolge. Es können auch Spalten hinzukommen
>> oder verschwinden. Wenn ein BLOB hinzukommt, den besagte Query nicht
>> braucht, zieht das Performance-Argument. Wenn eine Spalte verschwindet
>> oder umbenannt wird, funktioniert SELECT * unbeeindruckt, aber kann
>> auch die Applikation damit umgehen?
>
> Aber das trifft doch zumindest nicht bei Benutzung einer festen View zu,
> oder?

Von allein ändern sich weder Tabellen noch Views. Aber im Leben einer
Datenbank-Applikation ändern sich solche Sachen schon mal. Defensive
Programmierung schützt dann vor der eigenen Vergeßlichkeit. Gut, bei
VIEWs sollte das eher selten passieren. Aber von der generellen
Verwendung von Wrapper-Views zur Entkopplung von Datenbank-Struktur
und Anwendung halte ich eher wenig. Das frißt unnötig Ressourcen. Wenn
man eine Abstraktionsebene einziehen will, dann in Form von Objekten.

>> Aus manchen Programmiersprechen (z.B. C) kann man gar nicht über die
>> Namen zugreifen (bzw. es ist sinnlos aufwendig).
>
> Das bedeutet, da PHP in C geschrieben ist, setzt der bei Benutzung von
> mysql_fetch_assoc zwangsweise immer noch ein "SHOW COLUMNS" ab?

Nein. Das liefert der Server gratis bei der Antwort mit. Die Daten
werden von libmysqlclient gepuffert und können per mysql_fetch_fields()
& Freunden vom Client gelesen werden.

>> while (($id, $name, $datum)= $sth->fetchrow_array()) {

vs.

>> while ($res= $sth->fetchrow_hashref()) {
>> $id= $res->{"id"};
>> $name= $res->{"name"};
>> $datum= $res->{"created"};
>> }

> Gibt's in PHP auch: list($a, $b, $c) = mysql_fetch_row($res)

Ich weiß. Ist allerdings nicht so mächtig wie in Perl.

> Dennoch: Das erste was man mir sagte: "Tu dir 'nen Gefallen, greif immer
> über den Spaltennamen zu."
> Und mal ganz ehrlich es ist vor allem kürzer, über schöner lässt sich
> streiten - und je kürzer desto weniger offensichtlich für nachfolgende
> Leser (nagut, in diesem trivialen Fall vielleicht eher nebensächlich).

Naja, was kürzer ist, sieht man oben ja sehr schön. Und drei Spalten im
Ergebnis sind eher wenig. Wirklich interessant wird das ohnehin erst,
wenn man die API für prepared Statements nimmt und Ergebnisvariablen
bindet (bei PHP heißt das dann mysqli).

> PS: Liegen die komischen Sonderzeichen im zitierten Text an meinen
> Einstellungen?

Nein. Das liegt daran, daß mein $EDITOR kein Unicode kann. Und mein
Newsreader kann Zitate aus Unicode-Posts nicht nach Latin1 wandeln.


XL

Re: [OT] SELECT * und Weiterverarbeitung in PHP (Was: Re: SELECT* und Views...)

Jens Himmelrath schrieb:

>> $sql = "select * from tabelle";
>> $result = mysql_query($sql);
>> while (list($dbid,$dbname) = mysql_fetch_row($result))
....
> Gleichzeitig würde dieses Problem dann nicht mehr auftreten, wenn man
> das mysql_fetch_row durch ein mysql_fetch_assoc ersetzen würde.
> Oder übersehe ich was?

Hmm... Hier passt eine meiner Beobachtungen, die ich unlängst machen
durfte, noch am Besten.

Bei der Umstellung von Projekten eines Kunden von PHP4 auf PHP5 bin ich
über (symbolisch) solche Konstrukte gestolpert:

$sql = 'SELECT t1.*,
t2.*
FROM t1
JOIN t2 ON t1.id = t2.t1_id
...';

t2 enthält bspw. auch ein Feld 'id'.

Unter PHP4 erhielt man mit

$row = mysql_fetch_assoc($result);
print $row['id'];

den Wert von t1.id (also den des ersten vorkommenden 'id'-Feldes im
Result, unter PHP5 t2.id (also den letzten).

Das ist ein weiteres, generelles Argument gegen die Verwendung von
SELECT * in irgendeiner Form. IMHO. In diesem speziellen Fall hilft dir
auch mysql_fetch_assoc nix.

gruss, heli

Re: [OT] SELECT * und Weiterverarbeitung in PHP (Was: Re: SELECT * und Views...)

Helmut Chang wrote:
>
> Hier passt eine meiner Beobachtungen, die ich unlängst machen
> durfte, noch am Besten.
>
> Bei der Umstellung von Projekten eines Kunden von PHP4 auf PHP5 bin ich
> über (symbolisch) solche Konstrukte gestolpert:
>
> $sql = 'SELECT t1.*,
> t2.*
> FROM t1
> JOIN t2 ON t1.id = t2.t1_id
> ...';
>
> t2 enthält bspw. auch ein Feld 'id'.
>
> Unter PHP4 erhielt man mit
>
> $row = mysql_fetch_assoc($result);
> print $row['id'];
>
> den Wert von t1.id (also den des ersten vorkommenden 'id'-Feldes im
> Result, unter PHP5 t2.id (also den letzten).

Nach ist das
Verhalten von PHP5 konform mit der Dokumentation. Laut

mysql-fetch-assoc.xml?revision=1.1&view=markup>

ist das seit April 2002 so dokumentiert. Welche PHP4-Version war das
genau?

> Das ist ein weiteres, generelles Argument gegen die Verwendung von
> SELECT * in irgendeiner Form.

Full ACK.


XL

Re: [OT] SELECT * und Weiterverarbeitung in PHP (Was: Re: SELECT* und Views...)

Axel Schwenke schrieb:

>> den Wert von t1.id (also den des ersten vorkommenden 'id'-Feldes im
>> Result, unter PHP5 t2.id (also den letzten).
>
> Nach ist das
> Verhalten von PHP5 konform mit der Dokumentation. Laut
>
> > mysql-fetch-assoc.xml?revision=1.1&view=markup>
>
> ist das seit April 2002 so dokumentiert. Welche PHP4-Version war das
> genau?

Keine Ahnung. Mir wurde nur mitgeteilt, dass dies eines der Probleme bei
der Umstellung ist. Ich hab mir nicht weiter Gedanken darüber gemacht,
Und da ich nie niemals nicht unter keinsten Umständen irgendwo ein
SELECT * im produktiven Einsatz verwende, war mir auch die Tatsache, die
unter dem von dir genannten Link zu finden ist, nicht bewusst.

gruss, heli

Re: SELECT * und Views...

Axel Schwenke schrieb:

> Jens Himmelrath wrote:
>
>> PS: Liegen die komischen Sonderzeichen im zitierten Text an meinen
>> Einstellungen?
>
> Nein. Das liegt daran, daß mein $EDITOR kein Unicode kann.

Es gibt mittlerweile eine ganze Reihe Freeware-Editoren, die problemlos
mit UTF8 umgehen können, z.B. vi (Unix) oder Crimson Editor (Windows).

Gruß. Claus

Re: [OT] SELECT * und Weiterverarbeitung in PHP (Was: Re: SELECT * und Views...)

Helmut Chang schrieb:
> Jens Himmelrath schrieb:
>=20
> Hmm... Hier passt eine meiner Beobachtungen, die ich unlängst machen
> durfte, noch am Besten.
>=20
> Bei der Umstellung von Projekten eines Kunden von PHP4 auf PHP5 bin ich=

> über (symbolisch) solche Konstrukte gestolpert:
>=20
> $sql =3D 'SELECT t1.*,
> t2.*
> FROM t1
> JOIN t2 ON t1.id =3D t2.t1_id
> ...';
>=20
> t2 enthält bspw. auch ein Feld 'id'.
>=20
> Unter PHP4 erhielt man mit
>=20
> $row =3D mysql_fetch_assoc($result);
> print $row['id'];
>=20
> den Wert von t1.id (also den des ersten vorkommenden 'id'-Feldes im
> Result, unter PHP5 t2.id (also den letzten).
>=20
> Das ist ein weiteres, generelles Argument gegen die Verwendung von
> SELECT * in irgendeiner Form. IMHO. In diesem speziellen Fall hilft dir=

> auch mysql_fetch_assoc nix.
>=20
Na ja, SELECT t1.*, t2.* ... scheint mir schon noch mal eine Steigerung
des Wahnsinns zu sein. Das eine _kann_ leicht schief gehen, das andere
_wird_ fast mit Sicherheit schief gehen.

--=20
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Sibylle.Koczian@Bibliothek.Uni-Augsburg.DE