Curso de Fundamentos de Bases de Datos

Diseño de tablas MySQL con validaciones reales

Curso de Fundamentos de Bases de Datos

Contenido del curso

Manipulación de Datos

Diseño de tablas MySQL con validaciones reales

Resumen

Diseñar una tabla en MySQL no termina cuando el CREATE TABLE se ejecuta sin errores. Para que sirva en un sistema real necesitas validaciones, unicidad, defaults y timestamps que protejan la integridad de los datos desde la base.

¿Cómo definir un primary key numérico en MySQL?

La primera columna que toda tabla debería tener es un identificador numérico único. Una convención cómoda es nombrar las tablas en plural y la columna id en singular con el nombre de la entidad, por ejemplo client_id. Así, cuando veas ese mismo nombre referenciado en otra tabla, sabrás exactamente a qué apunta.

Este client_id se declara como entero y se acompaña de tres banderas clave: PRIMARY KEY, AUTO_INCREMENT y UNSIGNED. La primera lo convierte en la llave principal, la segunda delega en MySQL la responsabilidad de ir incrementando el número en cada inserción, y la tercera obliga a que todos los valores sean positivos [01:55].

¿Por qué usar UNSIGNED en un id? Porque elimina el riesgo de ids negativos al pasar por filtros o expresiones regulares, y conserva la cardinalidad del tipo extendiendo el rango hacia adelante. Si antes guardabas de -128 a 128, ahora guardas de 0 a 256.

¿Por qué el primary key no debe ser el email?

La regla práctica es que el primary key sea un dato propio de la base de datos, no del mundo exterior. Un correo electrónico, un número de pasaporte o una matrícula pueden cambiar, y si los usas como llave principal tendrías que actualizar todas las tablas que los referencian, arriesgando perder integridad [04:45].

La alternativa para identificadores universales son los uuid. PostgreSQL los implementa nativamente; MySQL no, así que en MySQL se trabajan como columna adicional, nunca como primary key.

¿Cómo aplicar UNIQUE y NOT NULL en columnas de negocio?

Aunque el email no sea la llave principal, sí merece protección. Agregarle la palabra reservada UNIQUE evita que dos registros guarden el mismo correo. Si intentas insertar uno repetido, MySQL lanza un error de duplicate key que tu aplicación puede capturar como excepción.

El teléfono se trata distinto. No conviene marcarlo como UNIQUE porque dos hermanos podrían registrar el mismo número de casa, pero sí pedirle NOT NULL para que nunca quede vacío. En MySQL, vacío equivale a null, y forzar un valor real evita huecos en datos de contacto.

¿Qué hace UNIQUE en MySQL? Garantiza que ningún otro registro de la tabla repita el valor de esa columna. Si insertas un duplicado, la base lanza un error de duplicate key y rechaza la operación.

¿Cuál es la diferencia entre DATETIME y TIMESTAMP?

Una tabla bien diseñada guarda cuándo se creó y cuándo se modificó cada tupla. Para esas columnas, MySQL ofrece dos tipos:

  • DATETIME: almacena fechas desde el año 1000 hasta el 9999. Útil si manejas datos históricos o astronómicos.
  • TIMESTAMP: guarda fecha y hora apoyándose en el epoch, el número de segundos transcurridos desde el 1 de enero de 1970. Es más eficiente y suficiente para sistemas modernos.

Para la mayoría de aplicaciones, TIMESTAMP es la elección future proof. La columna created_at se define como TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, de modo que si nadie envía un valor, MySQL llena el hueco con la fecha y hora actual [10:30].

¿Cómo actualizar automáticamente el modified_at?

La columna modified_at se construye igual, pero suma un trigger implícito: ON UPDATE CURRENT_TIMESTAMP. Cada vez que esa tupla se actualice, MySQL refresca el valor sin que tu aplicación tenga que enviarlo. Es convention over configuration puro: la base de datos hace el trabajo silencioso.

¿Cómo verificar la estructura con DESCRIBE y SHOW CREATE TABLE?

Después de ejecutar el CREATE TABLE, conviene auditar lo que MySQL realmente guardó. Tienes dos comandos útiles:

  1. SHOW TABLES: lista las tablas existentes en la base.
  2. DESC clients o DESCRIBE clients: muestra columnas, tipos, si admiten null, defaults y extras como auto_increment.
  3. SHOW CREATE TABLE clients: devuelve el SQL completo que recrea la tabla, incluyendo engine y charset.

Al revisar la tabla con DESC, puedes detectar errores sutiles. En el ejemplo, el email aparecía como nulo porque faltó el NOT NULL en la sentencia original. La corrección requirió hacer DROP TABLE clients y volver a crearla con la definición completa.

Habilidades y conceptos clave para diseñar tablas en MySQL

Dominar el diseño de tablas implica combinar varias decisiones:

  • Nombrado consistente de tablas en plural y columnas id en singular con sufijo _id [00:50].
  • Uso de PRIMARY KEY, AUTO_INCREMENT y UNSIGNED en identificadores numéricos [01:55].
  • Diferenciación entre datos internos del sistema y datos del mundo exterior para elegir la llave primaria [04:45].
  • Aplicación de UNIQUE y NOT NULL según las reglas de negocio de cada columna [07:10].
  • Selección entre DATETIME y TIMESTAMP según rango y eficiencia [09:50].
  • Configuración de defaults con CURRENT_TIMESTAMP y triggers ON UPDATE [11:20].
  • Inspección de la estructura con DESCRIBE y SHOW CREATE TABLE [13:40].

¿Cómo nombras tú tus columnas id en tus proyectos? Cuéntalo en los comentarios y comparte las convenciones que sigues en tu equipo.