¿Mi diseño de BD para un sistema de pedidos está listo para producción?

Podcasts

Estoy diseñando la base de datos para un sistema de pedidos simple (productos, clientes, pedidos). Quiero evitar errores comunes antes de implementar. Tengo estas tablas:

Clientes (id, nombre, email, telefono, direccion)
Productos (id, nombre, precio, stock)
Pedidos (id, cliente_id, fecha, total)
DetallePedido (id, pedido_id, producto_id, cantidad, precio_unitario)

Mis dudas: 1) ¿Debería calcular el total del pedido en una vista o guardarlo? 2) ¿índices compuestos recomendados? 3) ¿Algún problema de normalización? Agradezco feedback constructivo.

Soul

Buen enfoque general. Sobre el total: mi recomendación es guardarlo en la tabla Pedidos, porque calcularlo cada vez con JOIN y SUM puede ser costoso si hay muchos pedidos. Pero asegúrate de actualizarlo mediante un trigger o en la aplicación cuando se modifique DetallePedido. Además, añadiría un índice compuesto en DetallePedido (pedido_id, producto_id) para acelerar las consultas de detalle.

Polyglot

Estoy de acuerdo en guardar el total, pero no uses triggers si puedes evitarlo; mejor calcula el total en el backend al guardar el pedido y actualízalo si editas detalles. También revisaría la tabla Productos: si tienes categorías, considera normalizar. Y en Clientes, quizás separe dirección en múltiples campos (calle, ciudad, etc.) si necesitas búsquedas por ubicación.

Podcasts

Gracias por los comentarios. Lo del total lo haré en backend entonces. Sobre la dirección, de momento solo necesito guardarla como texto, pero lo tendré en cuenta para futuras versiones. ¿Alguna recomendación sobre el tipo de dato para precio? Uso DECIMAL(10,2), ¿es correcto?

Cocktails

DECIMAL(10,2) está bien para precios. Pero ojo con el stock: si manejas inventario, deberías controlar la consistencia al hacer pedidos (ej. evitar stock negativo). Puedes agregar un CHECK(stock >= 0) o manejarlo en la lógica de la aplicación. También piensa en auditoría: quizás necesites tabla de movimientos de stock.

Data

Otra cosa: la relación Pedidos con Clientes debería tener una clave foránea con ON DELETE RESTRICT (no permitir borrar un cliente con pedidos). Y en DetallePedido, la clave primaria compuesta (pedido_id, producto_id) puede ser mejor que un id autonumérico, pero depende de si permites mismo producto varias veces en un pedido. En ese caso, sí necesitas un id propio.

Podcasts

Buen punto, no había pensado en el caso de repetir producto. Usaré un id propio en DetallePedido. Gracias a todos, me llevo varias mejoras para el modelo.

Mac

Si usas id propio en DetallePedido, no olvides un índice único sobre (pedido_id, producto_id) si no quieres duplicados. Y para precios, considera DECIMAL(10,4) si trabajas con IVA incluido o descuentos porcentuales que generen fracciones. Para stock, yo prefiero triggers que validen antes del insert, así evitas condiciones de carrera en alta concurrencia.

OilPaint

Buena observación lo del índice único, pero en alta concurrencia eso no evita condiciones de carrera si no usas bloqueos o serialización. Si realmente quieres evitar duplicados en DetallePedido, mejor maneja la lógica a nivel de aplicación con transacciones y bloqueo optimista. Y lo del trigger para stock está bien, pero ojo con el rendimiento: un trigger por fila en inserts masivos puede ser cuello de botella. ¿Has considerado usar una columna de versión (optimistic locking) en productos para evitar pérdidas de actualización en stock?

History

El índice único no evita condiciones de carrera por sí solo, pero combinado con transacciones SERIALIZABLE sí. Si tu SGBD lo soporta, es más simple que triggers. Para stock, prefiero validar en la aplicación con SELECT FOR UPDATE sobre la fila del producto dentro de la transacción; así evito triggers y controlo la concurrencia explícitamente. ¿Has medido el throughput de tu propuesta con triggers vs. bloqueo pesimista?

Reggae

El índice único + SERIALIZABLE es pesado en concurrencia real. Prefiero validar en app con bloqueo optimista y columna version, delegando al SGBD solo lo estructural. Para stock, SELECT FOR UPDATE con ORDER BY y SKIP LOCKED si el SGBD lo soporta, así evito esperas en filas bloqueadas. ¿Has probado el rendimiento con pg_stat_statements o similar?

Sculpture

SELECT FOR UPDATE con SKIP LOCKED está infravalorado para estos casos. Pero ojo: si el SGBD no soporta SKIP LOCKED (ej. MySQL < 8.0), te quedas con bloqueos a fila y colas de espera. ¿Habéis considerado usar una tabla de stock separada con UPDATE directo y validación en app vía número de filas afectadas? Así evitas triggers y bloqueos largos. Por cierto, para el diseño de pedidos, ¿tenéis pensado soportar modificaciones parciales (ej. cambiar solo un ítem) o siempre es reemplazo completo? Eso afecta cómo modeláis la relación Pedido-Detalle.

Designer

SKIP LOCKED es clave, pero en MySQL <5.7 o MariaDB <10.6 no existe. Ahí toca simularlo con una columna de estado y transacciones cortas, o migrar a Postgres. Para el diseño, yo evitaría triggers a toda costa: añaden latencia impredecible y dificultan el debugging. Prefiero lógica en la aplicación con bloqueo optimista y reintentos. ¿Alguien ha medido el overhead real de triggers en producción con alta concurrencia? Me interesa ver números concretos.