Una PRIMARY KEY identifica cada fila; UNIQUE impide que se repita un valor o combinación de valores; y una FOREIGN KEY exige que una referencia corresponda a un registro válido en otra tabla. En Django, esas ideas se expresan con primary_key=True, unique=True y models.ForeignKey, aunque el comportamiento de borrado del ORM no es lo mismo que una cláusula SQL ON DELETE.
Qué diferencia hay entre PRIMARY KEY, UNIQUE y FOREIGN KEY
| Restricción | Qué garantiza | Identifica o relaciona filas | Uso habitual |
|---|---|---|---|
PRIMARY KEY |
Valores únicos y no nulos en una o varias columnas. | Identifica una fila. | Clave estable para encontrar una fila y permitir que otras tablas la referencien. |
UNIQUE |
Que no se repita un valor o una combinación de valores. | No designa por sí sola la identidad principal de la fila. | Proteger una regla de negocio, como un código de producto único. |
FOREIGN KEY |
Que el valor referenciado corresponda a un valor permitido en la tabla destino. | Relaciona filas de tablas distintas. | Vincular un pedido con un producto existente. |
En PostgreSQL 18, una tabla puede tener como máximo una clave primaria, aunque esta abarque varias columnas. PostgreSQL crea automáticamente un índice único para las columnas de esa clave. Una tabla puede tener varias restricciones UNIQUE, también sobre una o varias columnas. Documentación de PostgreSQL 18 sobre restricciones.
As an Amazon Associate I earn from qualifying purchases.
Una clave foránea no vuelve únicos los valores de la tabla que la contiene: muchos pedidos pueden referirse al mismo producto. En PostgreSQL, la referencia debe apuntar a columnas de la tabla destino que tengan una clave primaria, una restricción única o un índice único no parcial.
Qué pasa con NULL y cuántas columnas puede cubrir cada restricción
PRIMARY KEY
Sus valores no pueden ser NULL y deben ser únicos. Puede consistir en una columna o en un grupo de columnas; en el segundo caso, la combinación identifica la fila.
#1 Best Overall
UNIQUE
UNIQUE no significa automáticamente «obligatorio»: si una columna también debe tener valor, declara NOT NULL. El tratamiento de valores NULL en restricciones únicas depende del motor y, en algunos casos, de su configuración. No supongas que todos los sistemas se comportan igual.
FOREIGN KEY
Una clave foránea comprueba la validez de una referencia, no que esta sea obligatoria. Si la relación debe tener siempre un destino, la columna necesita además una regla de no nulidad. Los detalles de cómo se tratan los valores nulos dependen del esquema y del motor de base de datos.
Rank #2
Ejemplo SQL: productos y pedidos
CREATE TABLE productos (
producto_id integer PRIMARY KEY,
codigo text UNIQUE NOT NULL
);
CREATE TABLE pedidos (
pedido_id integer PRIMARY KEY,
producto_id integer REFERENCES productos (producto_id)
);productos.producto_ididentifica cada producto: no se repite y no puede ser nulo.productos.codigono se repite. En este ejemplo también es obligatorio porque se añadióNOT NULL; esa obligación no se desprende deUNIQUEpor sí solo.pedidos.producto_iddebe referirse a un producto válido. Tal como está definido, el campo no declara por separado que la referencia sea obligatoria.
Cómo se expresan estas reglas con campos de Django
En Django 5.2, las opciones de campo traducen las reglas a modelos. Este ejemplo deja que Django agregue una clave primaria automática a ambos modelos, hace único el código del producto y relaciona cada pedido con un producto:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
from django.db import models
class Producto(models.Model):
codigo = models.CharField(max_length=40, unique=True)
class Pedido(models.Model):
producto = models.ForeignKey(Producto, on_delete=models.PROTECT)primary_key=True identifica el registro
Al declarar un campo con primary_key=True, Django aplica también null=False y unique=True. Solo un campo puede marcarse así en el modelo. Si no declaras una clave primaria, Django añade una automáticamente; por eso puede aparecer un campo id aunque no lo hayas escrito.
Para una clave primaria compuesta, Django 5.2 ofrece CompositePrimaryKey. No confundas una restricción única sobre varios campos con una clave primaria compuesta: ambas imponen unicidad, pero la clave primaria cumple además la función de identificar la fila.
unique=True protege una regla de unicidad
En el ejemplo, unique=True indica que el valor de codigo no debe repetirse. No lo convierte en clave primaria. Si el campo también debe ser obligatorio, declara esa condición explícitamente; la configuración de nulabilidad y el tratamiento de valores vacíos pueden depender del tipo de campo y del motor.
Rank #4
ForeignKey crea una relación muchos-a-uno
models.ForeignKey(Producto, ...) representa una relación en la que varios pedidos pueden apuntar a un producto. Django suele crear una columna de base de datos llamada producto_id y un índice para el campo. La relación no exige por sí sola que cada producto aparezca en un pedido.
Qué hace on_delete y qué no hace
El argumento on_delete define cómo actúa Django cuando se borran objetos mediante sus operaciones de borrado. En el ejemplo, models.PROTECT ilustra una política que impide borrar el objeto relacionado cuando la protección es aplicable; es una elección de comportamiento, no una recomendación universal. La política adecuada depende de qué signifique conservar o eliminar los pedidos en tu aplicación.
Best Value
En Django 5.2, on_delete no crea por sí mismo una restricción SQL ON DELETE en la base de datos. Por eso, no interpretes models.CASCADE como prueba de que el motor tiene configurado SQL ON DELETE CASCADE. La documentación de Django describe esta opción como un comportamiento que el ORM emula al borrar objetos. Referencia de Django 5.2 para ForeignKey.on_delete.
Cómo elegir la regla correcta
- Usa una clave primaria para el identificador principal de cada fila.
- Usa
UNIQUEcuando una regla de negocio prohíba duplicados, pero el dato no tenga que ser la identidad principal. - Usa una clave foránea cuando una fila deba referirse a una fila válida en otra tabla.
- Añade una regla de no nulidad si el valor debe ser obligatorio; no deduzcas esa obligación de
UNIQUEo de la relación por sí solas. - Define el comportamiento de borrado según las consecuencias que deba tener en la aplicación, y distingue esa política del SQL que aplica el motor.
La sintaxis exacta de restricciones, los índices y ciertos detalles de NULL pueden variar según la base de datos y su versión. La documentación de PostgreSQL citada corresponde a PostgreSQL 18 y la referencia de campos a Django 5.2.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
