Necesitaba ya una cámara digital, y como preludio a la reflex que me compraré este verano, me he pillado una compacta mierdosa para hacerla polvo en cualquier situación chorra.



He ido a pasear al puerto al lado de mi casa y he hecho unas cuantas fotos. Estoy contento con la compra, puesto que la cámara es rápida, se enciende en apenas 4 segundos, y cada foto tarda en echarla unos 2 segundos. En movimiento desenfoca un pelín, pero el resultado es mucho mejor que lo que he visto yo en compactas. No voy a hablar de colores, y de características ni cosas así, porque sinceramente no tengo ni idea. Os pongo un par de fotillos para que veáis de qué va. 100 € en el MediaMartk de Alicante.

Si trabajamos a menudo con bases de datos muy grandes, con multitud de campos con diversos datos, este pequeño truco nos puede servir para mejorar la rapidez de la consultas que hagamos. Primero es necesario comprender la teoría.

(Voy a usar la sintaxis de MySQL porque es donde trabajo normalmente, aunque todo esto es aplicable a otros sistemas, puesto que es mera teoría).

Si queremos seleccionar todos los campos de una tabla o algunos en concreto, y cuando tenemos algun WHERE o LIMIT, normalmente hacemos lo siguiente:



De este modo el motor recorre fila por fila y va extrayendo los datos de cada campo y al final los devuelve, hasta aquí todo bien. Un par de ejemplos más, supongamos la estructura de nuestra tabla tal que:



Si queremos seleccionar el campo3, haríamos lo siguiente:



Pero esta consulta no está optimizada, puesto que el motor primero recorre 'campo1' y 'campo2' y los descarta porque no se los pedimos. Es decir, está obteniendo y descartando continuamente puesto que el 'campo3' está en medio de la fila.



Sabiendo esto, volvamos al primer ejemplo, teníamos:



¿Qué pasa con esta consulta? Pues que al pedirle a MySQL que saque todos los campos con la determinada condición, irá recorriendo la tabla, obteniendo aquellas filas completas cuyos datos no se incluyen en nuestra condición, por lo que es un gasto de recursos innecesario.

Esto se arregla facilmente haciendo lo siguiente:




Nótese que hemos hecho una subconsulta, de modo que primero seleccionamos solamente el campo_indice (que suele y debe estar al principio de tabla), y a continuación lo unimos a nuestra consulta principal, relacionando este índice, con lo que obtenemos todos los datos que necesitamos directamente sin tener que descarta nada (salvo los índices de aquellas filas que no cumplen la condición, pero esto no es optimizable).



No obstante, hay que saber decidir si esto nos sirve o no. Para bases de datos grandes sin duda supone ganar velocidad; sin embargo, en bases de datos pequeñas, hay que saber decidir si el coste de hacer una subconsulta es menor que seleccionar directamente e ir descartando aquello que no necesitamos. Siempre puedes perfilar la aplicación y hacer testing masivo para descubrirlo