Cómo decidir entre relación cliente-servicio y pedido en el modelo de datos?

[Ava.C]

Estoy reestructurando un sistema heredado y me encuentro con una duda persistente al diseñar las nuevas tablas. En mi caso, tengo entidades como "cliente", "pedido" y "artículo" donde un pedido claramente pertenece a un cliente y contiene varios artículos, pero también necesito registrar servicios puntuales asociados directamente a un cliente sin pasar por un pedido. Me pregunto si forzar todo a pasar siempre por un pedido sería artificial, o si debería permitir esa relación directa entre cliente y servicio, aunque eso cree dos caminos distintos para conectar datos con el mismo cliente. La idea de mantener la integridad referencial me da vueltas.

[Paisley_W]

Mi propuesta inicial es mantener Cliente y Pedido como relaciones claras con una tabla PedidoArticulo para vincular artículos a cada pedido. Para los servicios puntuales del cliente crea una tabla ServicioCliente con campos cliente_id servicio_id fecha detalles y deja la relación con Cliente sin obligar a pasar por Pedido. Así preservas integridad referencial sin forzar flujos artificiales y mantienes dos rutas de conexión limpias.

[Timothy14]

Me pasa que forzar todo a pasar por un pedido suena burocrático, si el cliente tiene un servicio directo que pueda existir sin pedir nada, ¿no aporta más realismo?

[Benjamin_P]

Quien dice que todo tiene que esquematizarse en una FK elegante, a veces una relación directa cliente servicio funciona y ya.

[Timothy84]

¿Qué pasa si el equipo decide que la ruta cliente servicio debe existir solo para ciertos tipos de servicios y otros deben ir por pedido?

[Ava.S]

En mi experiencia con sistemas heredados la mezcla funciona cuando el negocio exige flexibilidad. Puedes modelar Servicio como entidad y permitir una ruta directa desde Cliente, usando una tabla puente o campos opcionales para no duplicar datos. Todo debe alinearse con la integridad referencial y con las reglas de negocio para orientar migraciones y que las consultas no se vuelvan un laberinto.

[AbigailHJ]

La clave está en las reglas de negocio, la estructura de tablas no resuelve el flujo si no entiendes quién usa qué y cuándo