Sé que:
$sth->fetchrow_hashref devuelve un hashref de la fila recuperada de la base de datos,$sth->fetchrow_arrayref devuelve un arrayref de la fila recuperada de la base de datos, y$sth->fetchrow_array devuelve una matriz de la fila obtenida a partir base de datos.Pero quiero conocer las mejores prácticas sobre estos. ¿Cuándo deberíamos usar fetchrow_hashref y cuándo deberíamos usar fetchrow_arrayref y cuándo deberíamos usar fetchrow_array?
Podría hacer algo peor que leer DBI recipes por gmax.
Se señala, entre otras cosas:
El problema surge cuando el conjunto de resultados , por medio de una combinación, tiene uno o más columnas con el mismo nombre. En este caso, un arrayref reportará todos las columnas sin ni siquiera darse cuenta de que un problema era que, mientras que un hashref perderá las columnas adicionales
En general, yo uso fetchrow_hashref (me da alrededor de dos columnas con el mismo problema de nombre mediante el uso de alias en el SQL), pero recurro a fetch (AKA fetchrow_arrayref) si necesito que sea más rápido. Creo que fetchrow_array está ahí para personas que no saben cómo trabajar con referencias.
fetchrow_array() también es útil si solo está seleccionando _one_ column, en cuyo caso while (my $ whatever = $ sth-> fetchrow_array) {say $ whatever} DWIMs – mfontani
No uso ninguno de ellos desde que cambio todo mi código DB para usar DBIx::Class.
DBI tiene que trabajar más para presentar el resultado como un hashref que como un arrayref o como una matriz. Si lo máximo en eficiencia es un problema, es más probable que use el arrayref o array. Si esto es realmente mensurable es quizás más debatible.
Puede haber una diferencia de rendimiento aún más marginal entre la matriz y la matriz.
Si le resulta más fácil hacer referencia a las columnas por su nombre, utilice el hashref; si usar números está bien, entonces cualquiera de las notaciones de matriz está bien.
Si lo primero que va a hacer es devolver el valor de la función de búsqueda, o pasarlo a alguna otra función, entonces las referencias pueden ser más sensatas.
En general, no hay ninguna razón fuerte para usar una sobre la otra. El gotcha destacado por Ed Guiness puede ser decisivo si no está a cargo del SQL.
Cuando escribí YAORM para $ work, calculé todos estos en nuestro entorno (MySQL) y encontré que arrayref realizaba lo mismo que array, y hashref era mucho más más lento. Así que estoy de acuerdo, es mejor usar array * siempre que sea posible; Ayuda azucarar su aplicación para saber con qué nombres de columna se trata. Además, cuantas menos columnas capte, mejor evite las declaraciones SELECT * tanto como pueda: vaya directamente al SELECT <just the field I want>.
Pero esto solo se aplica a las aplicaciones empresariales. Si está haciendo algo que no es crítico en el tiempo, vaya a cualquier forma que presente los datos en un formato con el que pueda trabajar más fácilmente. Recuerde, hasta que empiece a refinar su aplicación, la eficiencia es la más rápida para el programador , no para la máquina. Se necesitan muchos millones de ejecuciones de su aplicación para comenzar a ahorrar más tiempo de lo que pasó escribiendo el código.
+1 para la evaluación comparativa antes de realizar afirmaciones sobre el rendimiento. –
Por otro lado, la trampa con el uso de una matriz junto con algo así como 'select * from table donde id = "blah"' significa que está a merced de la base de datos y el orden de las tablas en eso. Algo tan simple como que un DBA agregue una nueva columna en el medio de la tabla cambiará su matriz, mientras que un hashref lo ignorará. – Oesor