¿Es mejor normalizar hasta la muerte o aceptar algo de redundancia para performance?

Broadway

Estoy diseñando una base de datos para un sistema de e-commerce. Tengo una duda clásica pero que me trae de cabeza en este proyecto específico.

La tabla pedidos tendría: id, usuario_id, fecha, estado, total. Luego una tabla detalles_pedido con: id, pedido_id, producto_id, cantidad, precio_unitario.

Mi dilema: El precio_unitario en detalles_pedido. Purista de la normalización dice: "¡Es un atributo del producto! Solo guarda producto_id y saca el precio de la tabla productos cuando lo necesites". Pero... ¿y si el precio del producto cambia? Un historial de pedidos mostraría precios incorrectos.

La solución "correcta" sería tener un historial de precios de productos y relacionar detalle_pedido con un precio_id de ese historial. ¡Pero eso son 3 joins solo para mostrar un pedido!

En la práctica, veo que muchos guardan el precio redundante en detalles_pedido y punto. ¿Hasta dónde llega vuestra normalización? ¿Cuándo dicen "basta" por rendimiento o simplicidad?

Pongo un ejemplo de código de la estructura "purista":

SELECT
    p.id,
    u.nombre,
    dp.cantidad,
    ph.precio AS precio_unitario_historico
FROM pedidos p
JOIN usuarios u ON p.usuario_id = u.id
JOIN detalles_pedido dp ON p.id = dp.pedido_id
JOIN precio_historico ph ON dp.producto_id = ph.producto_id
    AND p.fecha BETWEEN ph.fecha_inicio AND ph.fecha_fin;

¡Un join extra solo por el precio! ¿Vale la pena?

Transit

En e-commerce, el precio en el detalle del pedido es dato histórico. Debe reflejar exactamente lo que pagó el cliente en ese momento. Guardarlo de forma redundante en la tabla detalles_pedido no es una "mala práctica", es necesario.

La normalización tiene como objetivo evitar anomalías de actualización. Pero aquí no quieres que el precio se actualice si cambia en productos. Son datos diferentes: precio actual vs precio de venta.

Tu ejemplo del join con precio_historico es correcto en teoría, pero en la práctica es un infierno de mantenimiento. ¿Qué pasa si un pedido se edita después de creado? ¿La fecha del pedido sigue siendo la válida para el precio? Se complica.

Mi regla: Datos transaccionales (lo que ocurrió) se snapshot. Datos de catálogo (lo que es ahora) se normalizan.

Minimalism

Discrepo un poco con el comentario anterior. La solución del historial de precios no es un "infierno", es un modelo robusto para empresas grandes donde el precio puede cambiar varias veces al día (oferta flash, costos variables).

El problema del snapshot directo en detalles_pedido es que pierdes la relación con la regla de negocio que generó ese precio. ¿Era un precio promocional? ¿Tenía descuento por volumen? Si solo guardas el número, luego no puedes analizar por qué se vendió a ese precio.

El join adicional tiene un costo, sí. Pero con índices apropiados en (producto_id, fecha_inicio) y si no tienes miles de precios históricos por producto, la diferencia es mínima. Prioriza la integridad del dato sobre una micro-optimización prematura.

Codeo una alternativa con tabla de reglas de precio:

CREATE TABLE precio_aplicado (
    detalle_pedido_id INT,
    precio_base_id INT,  -- referencia a precio_historico
    regla_descuento_id INT NULL, -- referencia a una promoción
    precio_final DECIMAL(10,2)
);

Así sabes el desglose.

Broadway

Interesantes ambos puntos. El ejemplo del precio_aplicado es potente, pero me preocupa la complejidad para un MVP. ¿No es overengineering para una tienda pequeña?

La idea de que el snapshot "pierde contexto" es cierta. No había pensado en el análisis posterior. Pero en mi caso, los descuentos se aplicarían a nivel de pedido, no por producto individual. Quizás una columna precio_original y otra precio_final en detalles_pedido, y el descuento se guarda en la cabecera del pedido.

Mi duda persiste en el volumen: Si tengo 100.000 pedidos con 5 productos promedio, son 500.000 filas en detalles_pedido. Agregar dos columnas decimales (12 bytes cada una aprox.) vs hacer un join a una tabla precio_historico que quizás tenga 10.000 filas... ¿La denormalización aquí realmente da una ganancia de performance tangible en consultas de reportes?

Calligraphy

Para responder tu pregunta final sobre performance: Sí, la ganancia es tangible. Un join menos, especialmente en consultas de reporting que agregan millones de filas, es significativo.

Pero el benchmark es fácil de hacer. Crea ambas estructuras con datos sintéticos (usa una herramienta para generar 500k detalles) y mide. Te apuesto a que la diferencia en una query de "ventas por mes" será de unos cientos de milisegundos. ¿Eso importa? Para un reporte batch nocturno, no. Para una API que muestra el historial del usuario en tiempo real, quizás sí.

Mi consejo pragmático: Empieza con la denormalización (guarda precio en detalle). Es más simple de desarrollar y entender. Si luego necesitas el historial de cambios de precio para el catálogo, créalo aparte. Mantén las transacciones simples y duplicadas. La normalización excesiva al inicio es una de las mayores causas de complejidad accidental.

Dicho esto, documenta por qué tomaste esa decisión en un comentario en el modelo. Algo como: -- precio_venta: Snapshot al momento de la compra. No actualizar.

Minimalism

Este debate toca el corazón de la ingeniería de software: teoría vs pragmatismo. Coincido con el último comentario: empieza simple.

Pero quiero añadir un patrón intermedio que uso mucho: Event Sourcing light. Guardas el snapshot (precio en detalle_pedido) y guardas un evento en una tabla de auditoría (eventos_precio) cuando un precio de producto cambia. Así tienes el historial por si luego necesitas reconstruir o analizar, pero no penalizas las queries frecuentes.

La consulta para el pedido no toca la tabla de eventos. Solo la usas para reportes de "evolución de precios" o si un cliente reclama y necesitas ver qué precio estaba vigente en una fecha exacta.

Esto es un buen compromiso. Te dejo un esquema:

-- Tabla principal (desnormalizada para performance)
detalles_pedido (
    ...,
    precio_unitario DECIMAL(10,2) NOT NULL -- Snapshot
);

-- Tabla de soporte (para integridad/historial)
cambios_precio_producto (
    producto_id INT,
    precio_anterior DECIMAL(10,2),
    precio_nuevo DECIMAL(10,2),
    fecha_cambio DATETIME,
    usuario_cambio_id INT
);

Lo mejor de ambos mundos.

Broadway

¡Gracias a todos! Me habéis dado un buen abanico de perspectivas. La opción del Event Sourcing light me convence mucho para mi caso. Parte de los requisitos es justamente poder auditar cambios en productos (precio, descripción), así que ya necesitaría una tabla de auditoría. Enlazar el concepto con el snapshot del pedido tiene sentido.

Al final, creo que la respuesta es: "Depende del contexto de negocio y del volumen". Para este MVP, voy a implementar:

1. Snapshot del precio en detalles_pedido (simplicidad, performance).
2. Tabla de auditoría de cambios de precio (para cumplir con requisitos de trazabilidad).
3. Un comentario en el código explicando la decisión, como bien dijeron.

Me quedo más tranquilo sabiendo que no hay una "verdad absoluta", sino trade-offs. ¡Buen debate!