Cita:
Iniciado por oso_reyes 
(...) ahora pido su ayuda para ver si ustedes tienen alguna otra recomendación, ya sea en relaciones, tipo de datos o tablas, (...)
Personalmente le veo varias cosas poco claras, y algunos problemas de redundancia nociva.
- No se entiende el concepto de catálogos, ni por qué hay tres tablas con semejantes estructuras. Es como si se estuviesen confundiendo las entidades del modelo E-R con las clases del modelo de clases del sistema,
y no son la misma cosa.
- No es correcto relacionar un catálogo con un usuario en esa forma, porque plantea que l catálogo puede existir aunque el cliente no exista, pero el cliente no puede existir sin un catálogo. A mi entender está mal analizado.
- Hay un precio unitario en el detalle de la venta que no debería estar, ya que el precio unitario es en todo caso un atributo del stock, o de las existencias, y no de la acción de venta. Lo es en la venta en un determinado momento del tiempo, pero eso no lo hace un atributo propio del detalle de venta. Sigue siendo parte del dominio del producto.
- Funcionalmente, una imagen no debe ser almacenada en la tabla (varias razones), sino la ruta relativa del archivo. E incluso no es buena idea ni siquiera eso, porque un producto bien podría tener N imágenes, por lo que debería ser una tabla independiente, relacionada con el producto.
- La FK de un catalogo no va en producto, por la misma razón mencionada en el caso del usuario.
- Conceptualmente, un servicio de reparación no está en un estado binario de Reparado/No reparado. En la realidad puede tener varios estados posibles (Reparado, Pendiente, Presupuestado, Aprobado, Terminado, y siguen). Ponerlo como Reparado/No reparado no es suficiente en ningún sistema que conozca.
... Puede haber mas, pero con esto alcanza para iniciar.