Hola,
Cita:
Iniciado por leonardo_josue 
... Lamentablemente (o afortunadamente) no hay un "mejor modelo" o un "modelo ideal" de BD's para estas cuestiones... esto depende completamente de tus necesidades. ...
Definitivamente no pudiste ponerlo mas claro, y exactamente ese era el punto clave en mi propuesta.
Cita:
Iniciado por leonardo_josue ... Desde mi punto de vista, HackmanC se enfocó más bien en un sistema de CLASIFICACIÓN DE PRODUCTOS, utilizando no un modelo E-R, sino más bien un modelo Jerárquico, ese es un enfoque distinto.
El modelo de HackmanC, insisto, está pensado en saber qué producto DEBES DE PONER en qué nevera (lo que facilitaría encontrar fácilmente esos productos y no tener necesidad de preguntarle a los empleados acerca de los huevos), ...
Tienes razón en parte, el modelo que yo mostré no es un modelo, era una visión gráfica de la distribución de los productos que tiene uno de los vendedores del mercado que está cerca de mi casa. Yo no diseñe una estructura, no demostré las relaciones, ni la estructura de las tablas. Si de alguna forma se llega a la conclusión que esa debería ser la estructura de las tablas en ese caso pues entonces estamos bien, por mi no hay problema.
La única parte donde mostré algo relacionado al área técnica fue en la estructura de la tabla Neveras X Productos, pero no dije de donde venía Tipo_Producto, ni Sub_Tipo_Producto (que le llamas categorías). Igual si se llega a la conclusión que esas son tablas de relación entonces al parecer seguimos bien, entonces deberían ser tablas de relación E-R, por mi no hay problema tampoco en este caso.
Es decir, yo no te contradigo, posiblemente tu mires un modelo en jerarquía. Aunque un verdadero modelo en jerarquía es completamente diferente, como el caso de las bases de datos No-SQL, las cuales conozco muy bien.
La única diferencía en el concepto inicial y el mio es que yo metí un concepto adicional llamado Sección, que me permite seccionar las frutas de los lácteos, aunque repito, yo no dije en donde iba.
Cita:
Iniciado por leonardo_josue ...
Código MySQL:
Ver original+--------------+-------------+
| id_categoria | descripcion |
+--------------+-------------+
| 1 | frutas |
| 2 | leche |
+--------------+-------------+
+-------------+--------------+-------------+
| id_producto | id_categoria | descripcion |
+-------------+--------------+-------------+
| 1 | 1 | manzana |
| 2 | 1 | pera |
| 3 | 1 | melocotón |
| 4 | 2 | entera |
| 5 | 2 | semi |
| 6 | 2 | desnatada |
+-------------+--------------+-------------+
Tus tablas NEVERAS y NEVERAS_PRODUCTOs, no necesitan tener ninguna modificación.
El único problema que miro yo en eso es que puedes poner las peras en la categoría de leche mas fácilmente que en el concepto de meter un discriminador adicional llamado sección. La sección me va a dar un discriminador inicial, por ejemplo, en mi interface gráfica, primero tengo que pedir la sección, después el producto. Clásicos Combo's relacionados, como Pais, Departamento, Localidad, Zona, etc., en jerarquía o cascada.
Ojo que yo nunca dije en que lugar exactamente iba Sección, podría ser igual a tu concepto de categorías, pero yo propuse además de las categorías, también secciones. Adicionalmente, en mi caso, lo que llamas categorías se llaman Tipo_Producto, Sub_Tipo, etc.
Cita:
Iniciado por asabervgz ... sé que no es lo más lógico pero solamente era para dejar claro que ciertos productos podrían tener diferentes variantes y otros no. ...
Si hay demasiadas variantes, es decir, no sabes exactamente cuantas cualidades van a tener los productos entonces no necesitas usar un tipo. En otras palabras, si no está normalizado, no se puede normalizar.
Saludos,
ps:
La parte de los huevos era un chascarrillo, común por estos lares.
Cita:
Iniciado por HackmanC
ps:
Muchas personas, simplemente va a tener Nevaras, Productos y posiblemente Neveras X Productos. De allí se va como caiga y como Dios les dé licencia.