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.
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.
Se puede hacer una inserción de dos maneras:
/*
Forma corta
*/INSERT INTO clientes VALUES ('Roberto Pérez', '55388214');
/*
Forma larga, pero conveniente
*/INSERT INTO clientes (nombre, telefono) VALUES ('Roberto Pérez', '55388214');
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í:
INSERT INTO clientes VALUES ('Roberto Pérez', '55388214');
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.
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.
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:
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:
INSERT INTO Usuarios(nombre, fecha_registro) VALUES(?, NOW());
Esto es lo que recomiendo (por ejemplo en PHP):
<?php
/*
Suponiendo que usamos PHP
*/$sentencia = "INSERT INTO Usuarios(nombre, fecha_registro) VALUES (?,?)";
$hoy = date("Y-m-d H:i:s");
$sentencia->execute([$nombre, $hoy]);
?>
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.
Hoy te voy a presentar un creador de credenciales que acabo de programar y que…
Ya te enseñé cómo convertir una aplicación web de Vue 3 en una PWA. Al…
En este artículo voy a documentar la arquitectura que yo utilizo al trabajar con WebAssembly…
En un artículo anterior te enseñé a crear un PWA. Al final, cualquier aplicación que…
Al usar Comlink para trabajar con los workers usando JavaScript me han aparecido algunos errores…
En este artículo te voy a enseñar cómo usar un "top level await" esperando a…
Esta web usa cookies.