Al diseñar una base de datos a veces no nos importa el nombre de las tablas, la notación, etcétera. Pero aquí hay algunos consejos que (según yo) sería bueno tomar en cuenta.
Nota: estos consejos aplican sobre todo a MySQL y PHP, pero igual podrían servir en otros motores, simplemente buscando las equivalencias para el código; porque la metodología es la misma.
Usa la notación de serpiente para la base de datos y para las tablas
A veces, usamos la notación de camello para ahorrar espacio del nombre de las variables.
Es decir, escribimos miTabla (usa 7 caracteres) en lugar de mi_tabla (usa 8 caracteres) pensando en que eso mejorará el rendimiento, cosa que no pasará. Además, usar la notación de serpiente trae ventajas significativas que se aplican en la vida real.
Por ejemplo, en Linux y MacOS la notación importa. No es lo mismo miTabla y mitabla. En Windows no importan, puedes hacer consultas a mitabla o miTabla y la tabla será la misma.
¿Y qué pasa si programas en ambos entornos? Si haces un programa, escribes el nombre de la tabla en minúsculas y lo pasas a un servidor que corra Linux, tendrás algunos errores, porque no existirá dicha tabla. Así que es mejor usar notación de serpiente.
La otra ventaja es que se ve más legible y limpio un nombre escrito_así que escritoAsí. Puede que parezca lo mismo, pero no lo es. Si nombras tus tablas y bases de datos de esta manera te lo agradecerás a ti mismo. Además, podrás exportar/importar bases de datos de cualquier sistema a otro, no importa si las mayúsculas cuentan o no.
Finalmente, al programar usa la notación que desees. Esta recomendación sólo aplica al nombrar tus bases de datos y sus atributos.
Al hacer un insert especifica cada columna, aunque sean muchas
Se puede hacer una inserción de dos maneras:
Ahora, por conveniencia podemos usar la forma corta y listo, nos ahorramos muchas cosas. Pero… ¿Qué pasa si añadimos otra columna a la tabla?
Por ejemplo, vamos a suponer que tenemos a millones de clientes guardados en la tabla (sólo con el nombre y el teléfono), pero ahora tenemos que agregar la columna correo_electronico. No pasa nada, agregamos la columna y listo, pero ahora, al hacer un insert así:
Marcará un error, ya que no coinciden las columnas. Esto empeora cuando son muchas columnas, cuando hay columnas desordenadas, datos, y otras cosas. Por eso es importante especificar a cuáles columnas queremos insertar.
Guarda la fecha de creación y la fecha de actualización
Esto es más que nada una recomendación. Es una buena práctica agregar a todas las tablas la columna fecha_actualizacion y fecha_creacion ( no necesariamente tienen que llamarse así).
De esta forma podremos saber, por ejemplo, cuándo se registró un usuario, desde cuándo es miembro un cliente, cuándo fue la última vez que alguien actualizó su perfil, la fecha de creación de un post, decirle al usuario que actualice su contraseña si ha pasado mucho tiempo y muchas cosas más.
No uses NOW()
Al guardar fechas puede que sea fácil usar NOW(), que nos devuelve el timestamp en el formato YYYY-MM-DD HH:MM:SS o algo como 2007-12-15 23:50:26.
Pues bien, esto es una mala práctica, porque no siempre vamos a poder cambiar la zona horaria del motor. Si estamos en un servidor propio, adelante, pero si no (cosa que se da en la mayoría de casos) estaremos en un grave problema.
Esto es debido a que cuando rentamos un servidor compartido la zona horaria es casi imposible de cambiar, o sólo se puede cambiar para una consulta; por lo que tendríamos que:
- Cambiar la zona horaria
- Ejecutar nuestra consulta
La opción que traigo es fácil: si queremos la fecha actual podemos usar el equivalente en el lenguaje de programación que usemos; no hay que dejarle toda la tarea al motor.
Este código es una mala práctica:
Esto es lo que recomiendo (por ejemplo en PHP):
Cambiar la zona horaria del lenguaje es más fácil que cambiar la del motor. Además, así aseguramos la compatibilidad, ya que nunca sabemos si en todos los gestores de bases de datos tendremos un equivalente de NOW()
Hasta aquí llega esto. Espero poder escribir más consejos.
