MySQL - Diseño tabla productos

 
Vista:

Diseño tabla productos

Publicado por antoine (4 intervenciones) el 15/04/2017 14:58:59
Buenas tardes.

Tengo una duda que por más vueltas que le doy, y tras leer varias recomendaciones, no termino de convencerme de cuál sería la mejor opción.

Estoy realizando un programa de gestión para una empresa, que trabaja con multitud de productos, los cuales se agrupan en diferentes familias, y que aparte de tener algunas características comunes (nombre, referencia, referencia del proveedor, nivel de stock, etc.) tienen otras muy específicas que van a depender exclusivamente del tipo de producto que sean.

Me explico más detalladamente.
Tenemos un producto, caja, que aparte de los campos comunes que he comentado anteriormente, tendría que definir también su largo, ancho, alto, calidad y presentación (campos específicos).
Por otra parte, tenemos otro producto, cesta, que aparte de los comunes, tendría que definir otros campos específicos, como capacidad, material y grosor.
Y así, con muchísimos más artículos de otras familias, que entre ellas en un momento dado pueden compartir algún campo (por ejemplo muchos tipos de productos necesitan definir el largo, ancho y alto) pero que siempre van a tener algún tipo de característica específica.

La gran duda que tengo a la hora de diseñar la base de datos es:

- OPCIÓN A: Hacer una megatabla donde dar cabida a todos los productos con todos los campos, estableciendo a que admitan nulos aquellos donde va a depender de la familia y que por tanto no van a tener valores para todos. Aquí me pregunto cómo implementaría la admisión de nulos, teniendo en cuenta que para algunos campos sus valores estarían relacionados con otras tablas a través de clave externa. Por ejemplo, para el tipo de producto caja, que tiene el campo específico calidad, habría una tabla denominada calidades que estaría relacionada mediante clave externa.

- OPCIÓN B: Hacer una tabla común, con todos los productos y sus campos comunes, y después una tabla para cada tipo de producto (familia), relacionadas cada una con la común a través de clave externa, y que contendrían los campos específicos para el tipo de producto en cuestión.
Esto me implica quebraderos de cabeza a la hora de implementar la creación de nuevos productos o su actualización, ya que en función del tipo debo guardar los datos en una u otra tabla, presentar los formularios al usuario en función de los campos necesarios, validar los datos enviados según el tipo de producto, etc.

¿Podéis orientarme sobre cuál opción veis mejor?

Gracias.
Saludos.
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
Imágen de perfil de Alejandro
Val: 42
Ha aumentado su posición en 2 puestos en MySQL (en relación al último mes)
Gráfica de MySQL

Diseño tabla productos

Publicado por Alejandro (11 intervenciones) el 15/04/2017 23:45:23
Hola antoine, yo me inclinaria por la segunda opción. Crearía una tabla principal que contenga aquellos atributos comunes entre todos los productos y luego una tabla para cada tipo de producto en particular, teniendo como FK id_producto que seria PK de la tabla principal.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Diseño tabla productos

Publicado por antoine (4 intervenciones) el 16/04/2017 14:18:53
Hola, Alejandro, muchas gracias por aportar.

La verdad es que entre las dos opciones me tira más la segunda, ya que pienso que tener una megatabla con muchos valores nulos no está del todo bien.
La única pega que le veo es que, como comentaba, a la hora de guardar nuevos productos, eliminarlos, y al actualizarlos (sobre todo en un hipotético caso en el que se quisiera cambiar el tipo de producto, algo raro pero posible), tendría que hacer comprobaciones previas sobre qué tipo de producto se va a guardar, eliminar o actualizar, para dirigirme a la tabla correspondiente, cosa que con la megatabla no sería necesario.

Por ejemplo, para el caso raro, pero posible, de que quisiera cambiar a un producto su tipo, tendría que eliminar sus datos de la tabla para el tipo en el que se había guardado, y grabar los nuevos datos en la tabla para el nuevo tipo elegido, sin contar ya con los datos a presentar en el formulario de creación, edición, al usuario, que deberían ir cambiando según el tipo.

Mi mayor duda es si merece la pena incrementar la complejidad por optar a esta organización de la base de datos (OPCIÓN B) que a mi entender está mejor que la OPCIÓN A.

Muchas gracias.
Saludos.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar