Diseño tabla productos

[annx10]

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.

[alpe2000]

Yo haria lo siguiente...

Una tabla con los productos, con los campos "comunes" entre todos. lo tipico...

ID_producto, NOMBRE_producto, etc. etc. etc.

Otra tabla donde poner las "caracteristicas" especificas de los productos por ejemplo.

ID_producto, CARACTERISTICA_producto, VALOR_caracteristica

Ejemplo:

TABLA productos

1,caja,etc, etc,
2,cesta,etc, etc

TABLA caracteristicas

1,largo,100
1,ancho,25
1,profundo,30
1,color,blanco
2,largo,200
2,material,plastico


ETC ETC...

Yo lo haria así, puesto que no cargaria la tabla productos con campos NULL para productos que no precisen de tales caracteristicas.

[annx10]

Hola, alpe2000, muchas gracias por aportar.

Por lo que veo tú aconsejas tomar el camino de la opción B aunque no exactamente como yo lo planteaba, es decir, una tabla para los campos comunes y otra tabla para todos los campos que son específicos y que por tanto llevarían nulos.
¿Qué hace más aconsejable hacerlo de esta manera a hacerlo como yo planteaba la opción B, que era una tabla para cada tipo de producto con sus campos específicos? La tabla de características que me planteas tendría al final también un montón de nulos, pues la compartirán todos los productos, ¿no? No pongo en duda que sea mejor cómo tu me lo planteas, es para entender porqué una opción sería mejor que otra, ya que además de hacerlo me interesa aprender.

Siguiendo tu ejemplo, como yo lo planteaba sería:

TABLA productos

1,caja,etc, etc,
2,cesta,etc, etc

TABLA cajas

1,largo,100
1,ancho,25
1,profundo,30
1,color,blanco

tabla cestas

2,largo,200
2,material,plastico

La verdad es que entre las dos opciones que yo planteaba, siempre me ha tirado más la B, pues el tener una megatabla con muchos nulos no me parece muy correcto.
Sin embargo, si lo hacía mediante la opción B, veía muy enrevesado algunos procesos como actualizar productos, crear productos, etc., porque al tener una tabla para cada tipo con los campos específicos, siempre debía plantear dónde registrar los datos aparte de en la tabla común.

[alpe2000]

Iniciado por annx10

¿Qué hace más aconsejable hacerlo de esta manera a hacerlo como yo planteaba la opción B, que era una tabla para cada tipo de producto con sus campos específicos?

No tengo ni idea de que es lo que lo hace más aconsejable, seguro que hay en el foro gente más especializada que yo en temas de rendimiento y de normalización.

Yo lo hago así, porque así tengo TODOS los productos en una sola tabla, y todas las caracteristicas de los productos en otra.

Será que me resulta más facil de trabajar así.

Iniciado por annx10

La tabla de características que me planteas tendría al final también un montón de nulos, pues la compartirán todos los productos, ¿no?

La tabla caracteristicas, NO tendría ningún NULL puesto que solo se crean los necesarios de cada producto.

Por ejemplo si el producto "CESTA" NO precisa de la caracteristica "PROFUNDIDAD", pues no se crea.

¿Lo entiendes?

De la forma que tu sujieres, separando cada "FAMILIA" de productos, te implica en el futuro a ir creando tablas de FAMILIAS cada vez que amplies los diferentes tipos de productos, y es más en el futuro cuando un producto, digamos con una caracteristica especial, de una familia en concreto, tienes que modificar la tabla para añadir esa caracteristica, que igual solo es para ese producto.

Parece lioso, pero a mi me resulta mas comodo de esa forma, ahora los más expertos supongo que te diran a cambio de prestaciones o de normalizacion como es mejor :D

[annx10]

Hola, alpe2000.

Tienes razón, había entendido mal lo que planteabas con la tabla 'caracteristicas'.
Si ahora lo he entendido correctamente, esa tabla 'caracteristicas' consistiría en los siguientes campos:
- ID_PRODUCTO
- CARACTERÍSTICA
- VALOR

De esa forma, se irían añadiendo sólo las características necesarias para cada producto. ¿Correcto?

Sin embargo, el problema que le veo a esto que planteas es ¿cómo defines ese campo "VALOR"? Dependiendo de la característica que vayas a guardar, su valor será más aconsejable que sea de un tipo u otro.
Por ejemplo, para guardar valores como el ancho, el largo, la profundidad, necesitaré un campo de tipo int, o decimal. Y si lo que quiero guardar es por ejemplo el material, necesitaré un varchar, o en un momento dado, optar por tener otra tabla externa con los distintos tipos de materiales y en la tabla características relacionarlo con clave foránea, guardando sólo el ID del material. Por tanto, no es viable tener un sólo campo para los diferentes valores de las diferentes características.

Sobre lo último que has comentado de que haya dentro de una familia un producto con una característica especial, no lo he entendido bien, ya que según lo planteo, dentro de cada familia, todos los productos recogidos tendrían las mismas características. Por ejemplo, no podría haber cajas con alguna característica especial que no tuvieran las otras cajas.

Igualmente, te agradezco todos los planteamientos que me has hecho. La mayor duda que tengo precisamente va por lo que comentabas del rendimiento y normalización, aspectos que a veces se contraponen y hay que sopesar si sacrificar un poco uno en beneficio del otro.

Saludos.

[alpe2000]

Iniciado por annx10

Hola, alpe2000.

Tienes razón, había entendido mal lo que planteabas con la tabla 'caracteristicas'.
Si ahora lo he entendido correctamente, esa tabla 'caracteristicas' consistiría en los siguientes campos:
- ID_PRODUCTO
- CARACTERÍSTICA
- VALOR

De esa forma, se irían añadiendo sólo las características necesarias para cada producto. ¿Correcto?

Correcto, justo así es como yo lo hago.

Iniciado por annx10

Sin embargo, el problema que le veo a esto que planteas es ¿cómo defines ese campo "VALOR"? Dependiendo de la característica que vayas a guardar, su valor será más aconsejable que sea de un tipo u otro.

Yo lo hago como texto, pues no preciso hacer "operaciones" con los valores, solo a modo informativo.

EJEMPLO:

PRODUCTO:
Cubo Princesa
Material: Plastico
Alto: 120 mm.
Diametro: 50 mm.
Asa: Metal


Si precisas hacer operaciones con los valores, entonces debes ver otras formas. O a través de programación cambiar el VAR por el tipo de dato que necesites.

Iniciado por annx10

Sobre lo último que has comentado de que haya dentro de una familia un producto con una característica especial, no lo he entendido bien, ya que según lo planteo, dentro de cada familia, todos los productos recogidos tendrían las mismas características. Por ejemplo, no podría haber cajas con alguna característica especial que no tuvieran las otras cajas.

Buenoooooo... en el mundo de los productos, la vida da muchas vueltas: jajjajajajja

Imagina esto, tu ya tienes tu tabla de PRODUCTOS_CAJAS hecha:

ID_producto, NOMBRE, REF, LARGO, ANCHO, ALTO, MATERIAL, PESO

y ya tienes digamos..... 5000 productos metidos, de pronto sale un nuevo tipo de caja que lleva unos enganches de metal, para poner un sistema de cierre.

Ahora toca modificar la estructura de la tabla para agregar el campo "enganches" para las nuevas cajas, y a todas las demas ponerle NULL o "NO" en ese campo.
Como lo hago yo, esto no es necesario, basta agregar a la tabla CARACTERISTICAS la entrada:

3,Enganches, Si; de metal superresistente



Pero si no es tu caso, pues adelante.....

[Libras]

Solucion muy buena, pero dejas de lado lo relacional de la base de datos, para ese tipo de soluciones mejor usar un NONSQL, ademas hay que meter las validaciones sobre programacion

[annx10]

Iniciado por alpe2000

Buenoooooo... en el mundo de los productos, la vida da muchas vueltas: jajjajajajja

Imagina esto, tu ya tienes tu tabla de PRODUCTOS_CAJAS hecha:

ID_producto, NOMBRE, REF, LARGO, ANCHO, ALTO, MATERIAL, PESO

y ya tienes digamos..... 5000 productos metidos, de pronto sale un nuevo tipo de caja que lleva unos enganches de metal, para poner un sistema de cierre.

Ahora toca modificar la estructura de la tabla para agregar el campo "enganches" para las nuevas cajas, y a todas las demas ponerle NULL o "NO" en ese campo.

Totalmente de acuerdo, alpe2000. Y ese es precisamente el problema en el que me veo, jajaja, productos muy heterogéneos con muchas características diferentes. La única agrupación en cierta medida es a través de las familias, donde más o menos se da cierta igualdad en cuanto a características.

Para casos quizás más sencillos, iría bien como tú planteas, registrando sólo los valores que haga falta en la tabla características, pero en mi caso es algo más complejo, necesitaré en algunos momentos hacer operaciones y ciertas consultas donde entrarán en juego las características y poniéndolas todas en un sólo campo de tipo texto no me irá bien.

Seguiré sopesando opciones y mientras tanto dejaré abierto aún el hilo por si alguien más puede aportar otro punto de vista.

Muchas gracias.
Saludos.