Cita: Pero aquí veo que si los clientes se relacionan con sus productos tal vez no es necesario relacionar los clientes con las ordenes ya que podría tomar el id del cliente directamente desde los productos o estoy equivocado?
Estas equivocado, porque estás mirando las cosas como procesos y no como entidades de un sistema. No son las mismas cosas.
Una orden de trabajo siempre
es de un cliente, por ende el cliente
siempre está relacionado a la orden.
Un
producto no pertenece a un cliente, o al menos no un producto como lo entendemos en análisis de sistemas orientados a BBDD. Un producto es algo que se le vende a un cliente, o bien un servicio que se le brinda a un cliente. Pero el producto no es del cliente en el contexto de la base de datos, ni aunque lo compre. En todo caso un cliente adquiere un producto, y esa adquisición se expresa en la factura de compra. Pero la relación con el cliente es indirecta: cliente->factura->producto.
¿Se entiende?
No existe relación directa entre un producto y un cliente. Es siempre transitiva.
Ahora bien, para otros usos, deberías empezar por definir qué es lo que entiendes por "producto" en tu sistema.
Cita: Pero también pienso que cuando quiera listar las ordenes de trabajo de algún cliente voy a tener que hacer un camino más largo para encontrar que ordenes corresponden a cada cliente.
Si respetas la logica del sistema, no, porque como ya te dije, la orden siempre es de un cliente.
La idea es esta:
- Un cliente solicita X trabajo (existe una tabla OrdenTrabajo).
- Una misma orden puede contener N tareas (existe una tabla detalleOrdenTrabajo)
- Un item puede requerir N productos (existe una tabla ProductosDetalleOrden y otra Producto).
- Una orden se cobra por medio de una factura (existe una tabla Factura), la cual puede abarcar varios items, ordenes o productos (tabla DetalleFactura.
- Un producto puede tener varios proveedores (tablas Proveedor y proveedorProducto).
Y aquí me planto, porque el diseño se va volviendo más complejo a medida que debes detallar las entidades que pueden requerirse. Creo que como visión te acerca al modelado.
De todos modos, cuando tienes tanta complejidad ya no puedes hacerlo con simples sentencias SQL, sino que debes recurrir a una herramienta de modelado, como MySQL Workbench, ya que hay que plantearlo como diagrama para ir viendo todos los componentes y sus relaciones.
Y todavía no hemos hablado de normalización de bases de datos...