Práctica: diseña una tabla con reglas e índice

La idea clave: diseña reglas antes de escribir sentencias

Una migración pequeña puede incluir varias decisiones distintas. Mezclarlas sin un plan suele producir columnas ambiguas, restricciones incompletas o índices que no responden a ninguna consulta real. Antes de abrir el editor, separa el requisito en cuatro preguntas: qué entidad vas a guardar, qué estados son inválidos, qué cambia después y cómo se buscarán las filas.

Convierte el requisito en un plan de esquema

1. Identidad. La tabla necesita una clave primaria para distinguir cada incidencia.
2. Relación. pedido_id debe apuntar a una fila existente de pedidos.
3. Estados válidos. El estado solo admite 'abierta' o 'resuelta' y comienza como 'abierta'.
4. Duplicados que no tienen sentido. Un mismo pedido no debe repetir el mismo código de incidencia.
5. Evolución. La prioridad se añade después y debe quedar entre 1 y 3, con 2 como valor predeterminado.
6. Acceso previsto. El índice seguirá el filtro habitual: primero estado y después prioridad.

Ejemplo guiado: una decisión por capa

Imagina una tabla más pequeña para guardar notas de un pedido. Un primer borrador podría separar la relación y el estado así:

CREATE TABLE notas_pedido (
  id INTEGER PRIMARY KEY,
  pedido_id INTEGER NOT NULL,
  texto TEXT NOT NULL,
  FOREIGN KEY (pedido_id) REFERENCES pedidos(id)
);

La clave primaria identifica la nota, NOT NULL evita que falten datos esenciales y la clave foránea expresa la relación con pedidos. Si más tarde la aplicación necesita distinguir notas internas y externas, ese cambio debe planificarse como evolución del esquema, no esconderse en una columna que ya significaba otra cosa.

Un error habitual

Práctica guiada: construye y evoluciona el esquema

Escribe tres sentencias. El laboratorio no se limita a buscar palabras: comparará el estado final de la tabla, sus restricciones, la relación y el índice con el esquema esperado.

CREATE TABLE incidencias_pedido (
  id INTEGER PRIMARY KEY,
  pedido_id INTEGER NOT NULL,
  codigo TEXT NOT NULL,
  detalle TEXT,
  estado TEXT NOT NULL DEFAULT 'abierta'
    CHECK (estado IN ('abierta', 'resuelta')),
  UNIQUE (pedido_id, codigo),
  FOREIGN KEY (pedido_id) REFERENCES pedidos(id)
);

ALTER TABLE incidencias_pedido
ADD COLUMN prioridad INTEGER NOT NULL DEFAULT 2
  CHECK (prioridad BETWEEN 1 AND 3);

CREATE INDEX idx_incidencias_estado_prioridad
ON incidencias_pedido(estado, prioridad);

Ronda autónoma: diseña antes de ejecutar

Si te bloqueas, separa integridad, evolución y acceso

1. Si dudas sobre columnas y tipos, vuelve a CREATE TABLE.
2. Si no sabes qué regla evita un estado inválido, repasa claves y restricciones.
3. Si el requisito apareció después de crear la tabla, revisa ALTER TABLE.
4. Si la duda es de rendimiento, vuelve a índices y empieza por la consulta que quieres acelerar.

Fuentes técnicas consultadas

La práctica usa sintaxis básica y deliberadamente portable, pero el comportamiento exacto de DDL, restricciones e índices depende del motor. La documentación oficial debe ser la referencia cuando prepares una migración real.

• PostgreSQL 18: Constraints.
• PostgreSQL 18: ALTER TABLE.
• PostgreSQL 18: CREATE INDEX.
• SQLite: CREATE TABLE.
• SQLite: ALTER TABLE.
• SQLite: Foreign Key Support.
• MySQL 8.4: ALTER TABLE.

Conceptos relacionados