Quote

Zu bloede Key namen: dafuer gibt's ja AS

Ja, das meinte ich mit

Quote

umgehen kannst du es dann mit einer Zuweisung der berechnung in einem leserlichen Namen im SQL.

vielleicht hätte ich es anders schreiben sollen.

Quote

dies hat ueberdies den Vorteil, dass man die Gross-/Kleinschreibung der Keys im Script bestimmen kann und sich nicht auf das, was in der DB vorkommt, verlassen muss, gerade wenn die Datenbank nicht von einem selbst stammt.

Das ergibt so wie du es schreibst für mich keine logik. Nach dieser logik kann man also auch kein "SELECT *" nutzen da man ja für alles mit "as" einen neuen Namen setzen muss, da die groß/kleinschreibung ja anders sein könnte. Damit hätte ich keinen Vorteil, und das SQL wird sogar noch länger als bei einem fetchrow_arrayref() den da kann ich mir die "AS ..." sparen.

Aber so nebenbei gesagt, du kannst folgendes machen.

Dann werden alle Keys automatisch in kleinbuchstaben umgewandelt.

Du kannst das Attribut aber auch auf dem Datenbank handle setzen, so musst du das nicht bei jeder Abfrage neu setzen.




----


Aber insgesamt wie du es schreibst sehe ich keine Vorteile mehr. Bei identischen Hash Keys musst du sowieso wieder manuel mit "AS" direkte Namen zuweisen. Zudem ist ein fetchrow_hashref langsamer als ein normalen fetchrow_array() und vorallem als ein fetchrow_arrayref()

Zitat aus perldoc DBI:

Quote

Because of the extra work "fetchrow_hashref" and Perl have to perform, it is not as efficient as "fetchrow_arrayref" or "fetchrow_array".

Es kann genau in dem Sonderfall nützlich sein wenn man ein "SELECT *" macht, wenn man alles oben beachtet. Ich finde das zu komplex.

Ein fetchrow_arrayref() ist performant und man muss da nicht so viele sonderfälle beachten. Ich meine aber immer noch das da noch etwas war was gegen fetchrow_hashref() spricht, ich weiß aber nicht mehr genau was es war.