PostgreSQL
Fundamentos del modelo relacional: tablas, filas, atributos, claves, dependencias y relaciones para representar información con integridad.
El modelo relacional no empieza con tablas ni con CREATE TABLE. Empieza con afirmaciones sobre el dominio: qué hechos existen, cómo se identifican y qué combinaciones de datos deben ser válidas.
El modelo relacional representa información mediante relaciones formadas por atributos y tuplas. En PostgreSQL, una tabla es la implementación práctica de una relación, pero pensar únicamente en “filas y columnas” oculta lo más importante: el significado de cada fila, las claves que la identifican y las reglas que separan estados válidos de estados inválidos.
Una tabla no debería responder solo “qué columnas tiene”, sino también:
¿Qué afirma cada fila?
→ ¿Cómo se identifica esa afirmación?
→ ¿Qué otras filas necesita para ser válida?
→ ¿Qué duplicados o combinaciones deben ser imposibles?Sin un modelo explícito, el esquema suele copiar la forma de objetos del backend o formularios de interfaz. Eso produce problemas como:
El modelo relacional ofrece una forma de describir hechos y dependencias para que PostgreSQL pueda consultarlos, combinarlos y protegerlos.
Piensa en cada tabla como una afirmación parametrizada.
Para una tabla products:
Existe un producto con:
- identidad id
- perteneciente a business_id
- identificado comercialmente por sku
- llamado nameCada fila completa esa afirmación con valores concretos.
Para order_items:
La orden order_id contiene el producto product_id
en cantidad quantity
al precio histórico unit_priceEste predicado explica por qué unit_price pertenece al item histórico y no debe consultarse siempre desde el precio actual del producto.
Conjunto de tuplas que comparten la misma estructura y representan el mismo tipo de hecho.
En teoría relacional, una relación no tiene duplicados ni orden. SQL, sin embargo, opera frecuentemente con multisets y puede producir filas repetidas en consultas.
Una combinación de valores que satisface el predicado de la relación. En PostgreSQL se materializa como una versión de fila visible bajo MVCC.
Propiedad nombrada de la relación. En una tabla corresponde a una columna, pero incluye más que un nombre: tipo, nullability, defaults y constraints.
Conjunto de valores permitidos para un atributo. Puede representarse mediante un tipo, un domain, un enum, un CHECK o una referencia a otra relación.
Cantidad de atributos de una relación.
Cantidad de tuplas. No debe confundirse con la cardinalidad conceptual de una relación entre entidades —uno a uno, uno a muchos— ni con estimaciones del planner.
Conjunto de atributos que identifica una tupla de manera única.
Supón el requisito:
Cada negocio administra productos. Un SKU identifica un producto únicamente dentro de su negocio.
Modelo:
CREATE TABLE products (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
business_id bigint NOT NULL REFERENCES businesses(id),
sku text NOT NULL,
name text NOT NULL,
UNIQUE (business_id, sku)
);El flujo de diseño es:
products representa productos, no inventario ni precio histórico de venta.business_id expresa ownership.id proporciona identidad técnica estable.(business_id, sku) protege la identidad natural del dominio.La surrogate key no reemplaza la regla natural. Sin el UNIQUE, podrían existir dos productos con el mismo SKU en un negocio aunque cada fila tenga un id distinto.
Una clase de aplicación puede agrupar datos por conveniencia:
class OrderView {
customerName: string;
items: Array<{ productName: string; quantity: number }>;
}Eso no significa que deba existir una tabla con JSON o columnas repetidas que imiten el objeto. La aplicación necesita una forma de lectura; la base necesita representar hechos e integridad.
La misma relación puede proyectarse en distintos objetos:
El modelo no debería acoplarse a una sola representación de UI.
SELECT id, name
FROM products;Aunque hoy parezca devolver por id, PostgreSQL puede cambiar el orden por:
Solo ORDER BY establece un contrato:
SELECT id, name
FROM products
ORDER BY name, id;Incluir un desempate estable evita que filas con el mismo nombre cambien de posición entre ejecuciones.
En álgebra relacional clásica, una relación no contiene tuplas duplicadas. SQL permite duplicados en resultados:
SELECT status
FROM orders;Puede devolver pending miles de veces. DISTINCT elimina duplicados del resultado, pero no sustituye una constraint de integridad.
Diferencia:
UNIQUE constraint
→ impide estados duplicados al escribir
DISTINCT
→ transforma el resultado de una consultaFiltra tuplas:
SELECT * FROM orders WHERE status = 'pending';Elige atributos o expresiones:
SELECT id, total_amount FROM orders;Combina tuplas relacionadas:
SELECT o.id, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id;Combina resultados compatibles. UNION elimina duplicados; UNION ALL los conserva.
EXCEPT, NOT EXISTS y anti-joins expresan ausencia relativa entre conjuntos.
Una tabla asociativa puede no necesitar un ID independiente:
CREATE TABLE user_branches (
user_id bigint NOT NULL REFERENCES users(id),
branch_id bigint NOT NULL REFERENCES branches(id),
role text NOT NULL,
PRIMARY KEY (user_id, branch_id)
);Aquí la combinación identifica la membership. Añadir id no elimina la necesidad de impedir memberships duplicadas.
Puede justificarse un ID separado cuando:
Un modelo aparentemente correcto puede perder semántica histórica.
Ejemplo incorrecto:
order_item solo guarda product_id y quantity
→ factura consulta products.current_priceSi cambia el precio, cambia retroactivamente la factura.
Modelo correcto:
CREATE TABLE order_items (
order_id bigint NOT NULL REFERENCES orders(id),
product_id bigint NOT NULL REFERENCES products(id),
quantity numeric(12,3) NOT NULL CHECK (quantity > 0),
unit_price numeric(14,2) NOT NULL CHECK (unit_price >= 0),
PRIMARY KEY (order_id, product_id)
);unit_price no es redundancia accidental; representa el precio pactado en ese hecho histórico.
No todo valor calculable debe almacenarse.
subtotal = quantity * unit_price puede:
La decisión depende de precisión, frecuencia de lectura, coste y necesidad histórica. Guardar un derivado sin estrategia crea inconsistencias.
JSONB es útil cuando una parte del dato es genuinamente semiestructurada:
Es mala sustitución cuando existen relaciones conocidas:
{
"productIds": [1, 2, 3]
}Ese array pierde foreign keys, cardinalidad clara y joins simples. La flexibilidad inicial se paga en integridad y consultas.
Un esquema no está completo si solo describe forma. También debe impedir estados inválidos:
quantity > 0.reserved_quantity <= quantity.Algunas reglas caben en constraints locales. Otras requieren transacciones, exclusion constraints, triggers o coordinación de aplicación.
Una columna nullable debe significar ausencia válida, no “todavía no diseñamos el concepto”. cancelled_at puede ser NULL porque no todas las órdenes están canceladas.
Una tabla gigante con decenas de columnas nullable puede indicar que se mezclaron entidades diferentes. Evalúa tablas por subtipo, composición o JSONB puntual.
Un staging table puede aceptar datos sucios para validarlos después. No conviertas ese diseño temporal en el modelo principal.
Una relación como (tenant_id, id) necesita asegurar que foreign keys y unique constraints conservan el tenant. Una FK solo por id puede permitir referencias cruzadas si los IDs no son globales.
Parece natural con un ORM, pero copia decisiones de código al almacenamiento y puede ignorar dependencias relacionales.
No permite integridad, indexing ni joins seguros. Usa tabla relacionada o array únicamente cuando el valor sea realmente atómico como conjunto.
Los IDs distintos no impiden duplicados del negocio.
Puede ocultar multiplicación de filas y añadir coste. Corrige cardinalidad y condición de join.
Produce paginación y resultados inestables. Usa ORDER BY completo.
Complementar no significa duplicar sin control: define fuente de verdad y sincronización.
ORDER BY.(business_id, sku) sigue siendo necesario si existe id?DISTINCT y UNIQUE?unit_price pertenece a order_items?SQL como lenguaje declarativo muestra cómo consultar y transformar relaciones describiendo resultados en lugar de programar recorridos fila por fila.