Respuesta

Restricciones (constraints) — son limitaciones de integridad impuestas sobre columnas o tablas para el control automático de la validez de los valores. Permiten:

• Proteger los datos contra entradas incorrectas;
• Mover parte de la lógica de aplicación a la base de datos (más confiable y más rápido);
• Verificar automáticamente las condiciones al insertar, actualizar o eliminar.

Tipos principales de restricciones:

• PRIMARY KEY — identificador único, prohíbe la duplicación y NULL.
• UNIQUE — prohíbe la duplicación de valores en una columna.
• FOREIGN KEY — integridad referencial, conexión con otra tabla.
• CHECK — verificación de una expresión arbitraria.
• NOT NULL — prohibición de valores NULL en la columna.

Ejemplo:

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INT REFERENCES users(id), -- clave foránea
  price DECIMAL(10,2) CHECK (price > 0),
  created_at TIMESTAMP NOT NULL
);

Pregunta engañosa

"¿Es la clave única (UNIQUE) automáticamente NULL-SAFE, excluyendo cualquier número de valores NULL en la columna?"

En realidad, en la mayoría de los SGBD (por ejemplo, PostgreSQL, MySQL) la restricción UNIQUE permite varias filas con el valor NULL, ya que NULL se considera "desconocido". Esto a menudo conduce a la duplicación inadvertida de valores vacíos.

Ejemplo:

CREATE TABLE test (
  id INT PRIMARY KEY,
  code VARCHAR(10) UNIQUE
);

INSERT INTO test (id, code) VALUES (1, NULL), (2, NULL); -- pasará

Ejemplos de errores reales debido a la falta de conocimiento de los matices del tema

---

Historia

La aplicación permitía el registro por correo electrónico, la columna era UNIQUE, pero NO NOT NULL — en la tabla había una decena de usuarios con email NULL, lo que causó problemas al integrarse con servicios externos.

---

Historia

En el sistema de reservas de boletos olvidaron agregar la clave foránea a la tabla de pagos — como resultado, aparecieron pagos no vinculados a ningún pedido, lo que dificultaba realizar reembolsos a los usuarios.

---

Historia

Restricción CHECK para descuento: discount > 0. Se olvidó una situación límite para 0. Resultado: el sistema aceptaba solo descuentos mayores a 0, y la ausencia de descuento (0) rompía la lógica de negocio.