Creación de tablas

La sentencia CREATE TABLE

CREATE TABLE crea una tabla: construye el recipiente vacío, con sus campos, sus tipos y sus reglas. No guarda ningún dato todavía. Después de ejecutarla, la tabla existe y está lista para recibir registros; antes de ejecutarla, no hay dónde poner nada.

Su forma es siempre la misma: el nombre de la tabla y, entre paréntesis, la lista de campos separados por comas. Cada campo lleva su nombre, su tipo y —si hace falta— sus restricciones.

CREATE TABLE socios (
    id        INT AUTO_INCREMENT PRIMARY KEY,
    nombre    VARCHAR(80)  NOT NULL,
    documento VARCHAR(15)  NOT NULL UNIQUE,
    correo    VARCHAR(120),
    alta      DATE         NOT NULL,
    activo    TINYINT(1)   NOT NULL DEFAULT 1
);

Las dos cosas que hay que saber de esta sentencia están desarrolladas en la Unidad 3: los tipos de datos que puede llevar cada campo y las restricciones —PRIMARY KEY, FOREIGN KEY, NOT NULL y UNIQUE— que son las reglas que la base va a hacer cumplir sola. Acá interesa lo que es propio de esta unidad: cómo cambia la misma sentencia según el gestor.

La misma tabla en los dos dialectos

Es la misma tabla de socios, escrita para cada gestor:

-- MySQL / MariaDB
CREATE TABLE socios (
    id        INT AUTO_INCREMENT PRIMARY KEY,
    nombre    VARCHAR(80)  NOT NULL,
    documento VARCHAR(15)  NOT NULL UNIQUE,
    correo    VARCHAR(120),
    alta      DATE         NOT NULL,
    activo    TINYINT(1)   NOT NULL DEFAULT 1
);

-- SQLite
CREATE TABLE socios (
    id        INTEGER PRIMARY KEY AUTOINCREMENT,
    nombre    TEXT    NOT NULL,
    documento TEXT    NOT NULL UNIQUE,
    correo    TEXT,
    alta      TEXT    NOT NULL,
    activo    INTEGER NOT NULL DEFAULT 1
);

Sobre la clave automática hay un detalle propio de SQLite que conviene conocer: INTEGER PRIMARY KEY se completa solo, incluso sin la palabra AUTOINCREMENT. Lo que agrega AUTOINCREMENT no es el completado automático sino una garantía extra: que un número que ya se usó no se vuelva a usar nunca aunque se borre el registro. Sin él, si se elimina el último registro, el número siguiente puede repetirse. Con él, no. Para la mayoría de los casos alcanza con INTEGER PRIMARY KEY; cuando el identificador se usa en documentos o comprobantes que ya se entregaron, conviene el AUTOINCREMENT.

Cambiar y borrar tablas

Una tabla se puede modificar después de creada, y también eliminar. Las dos instrucciones son parte de la misma familia:

-- Agregar un campo nuevo
ALTER TABLE socios ADD COLUMN telefono VARCHAR(30);

-- Cambiar el tipo o el largo de un campo (en MySQL)
ALTER TABLE socios MODIFY COLUMN correo VARCHAR(160);

-- Eliminar un campo
ALTER TABLE socios DROP COLUMN telefono;

-- Eliminar la tabla completa, con todos sus datos
DROP TABLE prestamos;

Hay un detalle tranquilizador: si otra tabla referencia a esa por una clave foránea —como prestamos con socios—, la base va a impedir el DROP. Es una protección, no un error: significa que hay registros que dependen de esa tabla y que borrarla los dejaría apuntando al vacío.

En cuanto a ALTER TABLE, funciona siempre y conviene usarlo con criterio. Agregar un campo es seguro, sobre todo si se le pone un DEFAULT para los registros que ya existen. Cambiar el tipo de un campo con datos adentro es otra cosa: si se pasa de texto a número, o se acorta el largo, hay registros que van a quedar mal y el resultado depende de qué había guardado. En un proyecto en marcha, ese tipo de cambio se planifica y se prueba en una copia primero. Mientras se está aprendiendo y la tabla tiene datos de prueba, lo más limpio es borrarla y crearla de nuevo con el diseño corregido.

Resumen

• CREATE TABLE crea la estructura vacía: no guarda datos.
• El desarrollo completo del tema —tipos de datos, restricciones e integridad referencial— está en la Unidad 3.
• El mismo diseño se escribe distinto en cada dialecto: INT/INTEGER, VARCHAR/TEXT, DATE/TEXT.
• En SQLite, INTEGER PRIMARY KEY se completa solo; AUTOINCREMENT agrega que un número no se reutilice.
• ALTER TABLE cambia la estructura; DROP TABLE la elimina con todos sus datos y sin vuelta atrás.
• Las claves foráneas impiden borrar una tabla de la que dependen otras.
• Cambiar el tipo de un campo con datos adentro no es un cambio trivial: se prueba en una copia.

Ver qué es CRUD