Me aburro, así que me ha dado por escribir un post sobre un par de “imprescindibles” a la hora de andar jugando con una base de datos. Voy a poner los consejos que se me vengan a la cabeza, pero si conocéis alguno que me deje, pues comentadlo y edito el post añadiéndolo (con el correspondiente mensaje de agradecimiento):
- Nunca hagas Select * From TablaX, la sobrecarga que provoca una sentencia de esta clase es bastante considerable. No soy ningún experto en BDs pero, a bote pronto, se me ocurre que el sistema gestor tendrá, primero, que ir a su catálogo a ver qué columnas tiene esa tabla para luego ir recuperándolas. Por desgracia, como no hay ninguna clase de filtro ni de filas ni de columnas, recuperará la tabla ENTERA y si hablamos de una tabla medianamente larga, eso es mucha información.
- No hagas Select * From TablaX where criterioZ, includo aunque quieras recuperar todos los campos de la tabla para esa tupla concreta, es preferible describir cada uno de los campos en la sentencia, es decir, hacer un select campo1, campo2, …, campoN From TablaX where criterioZ porque así evitas que el SGBD tenga que, de nuevo, consultar el catálogo para ver qué campos quieres.
- En entornos web, procura tener el menor tiempo posible abiertas las conexiones con la BD porque eso reduce la escalabilidad. Es decir, que si por alguna absurda razón (tan absurda como salir en portada en Menéame o Barrapunto) tu web sufre un incremento radical de las visitas, el número de conexiones crecerá proporcionalmente y puede que tu aplicación web pete si no estás gestionando bien dichas conexiones y haciendo su vida lo más corta posible. Es preferible que un usuario espere un poco más para abrir y cerrar la conexión, que el hecho de no poder acceder a la información porque el número límite de conexiones se ha alcanzado.
- Parametriza las consultas, es la mejor forma de evitar errores y problemas extraños cuando tu base de datos espera un determinado tipo para una columna de una tabla y le metes otro diferente. Parametrizando las consultas, desde el propio código va a ver qué tipo de datos tienes que ponerle y si te equivocas y le pasas un float a una consulta que espera un int, lo verás rápidamente.
- Si la base de datos que utilizas soporta procedimientos almacenados, no dudes en usarlos. Es la mejor opción posible, puesto que aisla la lógica de tu aplicación (lógica de negocio) de las cadenas SQL necesarias para persistir su información. Las ventajas son muchas, pero sólo por nombrar algunas, tendríamos:
- Una base de datos más optimizada. Debido a que las sentencias SQL están dentro de la BD y no dentro de la aplicación, el sistema gestor de la misma puede realizar las mejores optimizaciones y planificaciones para un mayor rendimiento a la hora de ejecutar dichas consultas o actualizaciones. En cambio, si las consultas permanencen en la aplicación, la optimización se tendrá que hacer dinámicamente en tiempo de ejecución, no siendo tan óptimo el resultado.
- Más control sobre las consultas. Combinado con las consultas parametrizadas, permite eludir la gran mayoría de mecanismos de inyección de SQL. Dado que en los procedimientos almacenados se define claramente qué va a hacer dicho procedimiento, no hay lugar para añadir nuevas “consultas” maliciosas, máxime si se pasan tipos de datos correctos mediante la parametrización de la consulta.
- Mejor gestión de la propagación de los cambios. Un simple cambio de nombre en una columna de una tabla puede suponer cambiar N mil sentencias SQL de la aplicación si están embebidas en la misma. En cambio, si se están usando procedimientos almacenados, basta con cambiarlo en los procedimientos que utilicen dicha columna.
- Otras muchas ventajas que no conozco, puesto que mi conocimiento sobre el tema es bastante limitado
- No utilices cuentas de administrador para conectar tu aplicación a la base de datos. En general, como regla general para cualquier cosa que tenga que ver con la informática, ya sea desarrollo de aplicaciones o administración de las mismas, siempre, siempre, se deben hacer las cosas con el menor número de privilegios necesarios, nunca más. Eso incluye no usar la cuenta de Administrador de tu sistema operativo para navegar por Internet (como estoy haciendo yo ahora mismo, todo sea dicho 
).
Ahora mismo no se me ocurre ninguno más, pero estoy abierto a sugerencias y críticas.
EDIT: Este consejo lo envía Luther
NUNCA pasar directamente el input del usuario a la base de datos! Hay que parsear los datos: ALL INPUT IS EVIL!!!!!
Si poneis dos textboxes (Usuario y contraseña) y haceis esto, estais castigados de por vida porque os van a meter la inyeccion SQL por el culo:
SELECT u_id
FROM logins
WHERE username = ‘$usuario’
AND password = ‘$password’
