¿Qué pensarias, si veis el código de una página que, para listar 10 registros hace 11 consultas a la base de datos? Una para obtener el identificador de los registros a mostrar, y otra para cada identificador/registro.
a. Que el programador es un escéntrico
b. Que el programador no tiene ni puta idea
c. Que el programador es un genio
Os voy a explicar en qué caso la respuesta c es la correcta. Pero primero, dos pregunas más.
¿Qué pensarias, si ves el código de una página que, para listar 10 registros, hace una consulta que devuelve 42.358 registros de casi 8 Kb cada uno (casi 330 Mb)?
a. Que el programador no tiene aprecio alguno por el hardware
b. Que el programador es un descuidado
c. Que la base de datos no ofrece manera de evitarlo
La respuesta correcta es, nuevamente, la c. Porque mientras que MySQL tiene la posibilidad de solicitar el rango de registros que vas a mostrar en un listado paginado (LIMIT), esto no es completamente posible con SQL Server 2000. Pero aún se pone más interesante …
¿Que pensarias, si ves el código de una página que, despues de traerse casi 300 Mb de registros, los mete en un array en memoria?
a. Que el programador esta mosqueadisimo con el departamento de administradores de sistemas
b. Que el programador obtuvo su calificación en una tómbola
c. Que el programador esta utilizando un componente sin saber qué hace ese componente
Pues para no variar, la respuesta correcta es la c.
La explicación.
Un buscador realiza consultas sobre una tabla con más de 100.000 registros, aunque el máximo que puede recuperar (debido a un filtrado mínimo) son algo más de 42.000 registros.
Se componía una consulta tal como “SELECT * FROM v_Whatever WHERE …” que básicamente tenía dos problemas:
1. No eran necesarios todos los campos que devuelve
2. La vista realizaba internamente un “cast” de dos campos tipo “text”, que además no se usaban en el listado.
Luego se utilizaba para recuperar estos registros un componente que permite paginar el listado, y que para su propia comodidad (a la hora de saltar de un registro a otro) utilizaba la función GetRows de ADO que vuelca los registros a un array.
Después de un poco de investigación, y de inspiración divina -lo confieso-, la solución ha sido construir una consulta tal como “SELECT idRegistro FROM v_Whatever WHERE …” y después dentro de la iteración del listado, hacer una consulta tal como “SELECT * FROM v_Whatever WHERE idRegistro=…” que aún prodía mejorarse con un “WHERE idRegistro IN (…, …, …)” pero … bah! atomarporculo, así va bien.
El resultado más apreciable es una página que carga muuucho más rápido.
La moraleja.
Me considero un desarrollador bastante convencido (debe ser la edad) de la reutilización, pero recurrir al copy-paste sin cuestionarselo, y sin curiosidad, es jugársela.
Y eso que tenemos en la pared el siguiente recorte:
“Do you chew gum you find on the street?”
También he de decir, al margen del tema principal, que aunque me gusta la reutilización, también me gusta la evolución, con lo cual cuando utilizo un componente que he desarrollado, no me pregunto solo si cumple mis necesidades, sino también si puede mejorarse para la ocasión, o qué aprendí de la última vez que lo usé, con lo cual, al final, reutilización-reutilización no hago casi nunca 
) jejeje.
