Crear tablas con relaciones lógicas en MySQL

Construir bases de datos confiables empieza por definir relaciones lógicas claras y aplicar buenas prácticas al crear tablas. Aquí verás cómo vincular columnas por ID, leer errores y warnings útiles de MySQL, inspeccionar estructuras con comandos esenciales y evitar pérdidas irreversibles con DROP, todo con un enfoque práctico y directo.

¿Cómo se relacionan lógicamente las tablas sin claves foráneas?

En este enfoque, la relación entre tablas es lógica, no dura: no hay restricción activa y puede existir un libro sin autor. La vinculación se hace por ID coincidentes y tipos de datos iguales en ambas tablas.

• Usa el mismo tipo y atributos en las columnas relacionadas: por ejemplo, INT UNSIGNED en ambas tablas.
• Define la llave primaria solo en la tabla dueña del dato (authors), y como entero simple en la referenciada (books).
• Aclara criterios de nulabilidad: por ejemplo, nombre NOT NULL y país opcional.
• Adopta una convención de estilo: palabras reservadas en mayúsculas y nombres de tablas/columnas en minúsculas para mejorar lectura.

Ejemplo de tabla de autores y referencia lógica en books:

CREATE TABLE IF NOT EXISTS authors (
  author_id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(100) NOT NULL,
  country_code VARCHAR(3) NULL
);

-- En books, author_id es solo referencia lógica (no PRIMARY KEY)
-- Debe coincidir el tipo: INT UNSIGNED.
ALTER TABLE books
  ADD COLUMN author_id INT UNSIGNED;

Claves prácticas:

• PRIMARY KEY y AUTO_INCREMENT donde nace el dato (authors).
• En la otra tabla, la columna es solo referencia y no controla la operación de esa tabla.
• Mantén coherencia de tipos siempre que una columna relacione dos o más tablas.

¿Qué buenas prácticas y comandos evitan errores al crear tablas?

MySQL ofrece mensajes de error y warnings muy descriptivos. Úsalos a tu favor y protege tus workflows.

• Crea tablas de forma idempotente con IF NOT EXISTS.
• Verifica si ya existen tablas con SHOW TABLES.
• Lee advertencias con SHOW WARNINGS si ves “One warning”.
• Comprueba contenido inicial con SELECT.

Fragmentos útiles:

-- Crear sin romper el flujo si la tabla ya existe
CREATE TABLE IF NOT EXISTS authors (...);

-- Ver tablas disponibles
SHOW TABLES;

-- Consultar advertencias tras un “Query OK, 1 warning”
SHOW WARNINGS;

-- Verificar que está vacía
SELECT * FROM authors;

Cuidado extremo con DROP: es un “delete sin papelera”. Borra estructura y datos.

-- Confirmar dos veces antes de ejecutar
DROP TABLE authors;  -- irreversible sin respaldo

Notas clave:

• IF NOT EXISTS evita errores que pueden romper un workflow automatizado.
• Un warning no rompe la ejecución, pero debe revisarse.
• DROP elimina todo; más adelante se puede usar TRUNCATE cuando solo se requiere vaciar, no borrar estructura.

¿Cómo inspeccionar estructura, comentarios y palabras reservadas?

Antes de modificar o consultar, entiende la estructura con comandos de inspección. Además, evita choques con palabras reservadas usando comillas invertidas.

• Usa DESCRIBE o su acrónimo DESC para ver columnas y tipos.
• Emplea SHOW FULL COLUMNS FROM para ver comentarios, collation y privilegios.
• Si una columna necesita un nombre reservado (p. ej., YEAR), encierra el identificador con backticks.

Comandos clave:

-- Estructura de una tabla
DESCRIBE authors;
DESC books;

-- Estructura ampliada: comentarios y más metadatos
SHOW FULL COLUMNS FROM books;

-- Evitar ambigüedades con palabras reservadas
CREATE TABLE ejemplo (
  `year` INT,      -- nombre reservado protegido
  `sum` DOUBLE     -- otro ejemplo de identificador sensible
);

Habilidades y conceptos reforzados:

• Relaciones lógicas por ID: coherencia de tipos y ausencia de restricción física.
• Convención de estilo: SQL en mayúsculas; identificadores en minúsculas para lectura clara.
• Tipos de datos: INT, DOUBLE, VARCHAR, TINYINT como bandera booleana.
• Nulabilidad: uso de NOT NULL y posibilidad de NULL donde aplica (p. ej., country_code).
• Manejo de errores y warnings: lectura del mensaje “near ...” y uso de SHOW WARNINGS.
• Seguridad operativa: uso responsable de DROP TABLE.
• Metadatos de columnas: comentarios, collation y permisos con SHOW FULL COLUMNS.
• Identificadores con backticks: protección ante palabras reservadas y definición de alias sin ambigüedades.

Más adelante, se aplicarán tipos de fecha y se construirá la tabla de clientes como pilar del proyecto, integrando estos principios desde el diseño.

¿Tienes dudas o quieres compartir una práctica que te funcione? Deja tu comentario y conversemos.