Pensando en voz alta aquí, pero tal vez sería útil ver algunos atributos (como Rojo, Amarillo y Verde) como 'etiquetas' en lugar de 'categorías' y manejarlos con lógica separada. Eso le permitiría mantener el modelo de Conjunto anidado y evitar la duplicación innecesaria. Además, te permitiría mantener tus categorías más simples.
Todo está en cómo piensas en la información. Las categorías son solo otra forma de representar atributos. Entiendo que su ejemplo fue sólo para fines ilustrativos, pero si va a clasificar la fruta por color, ¿por qué no categorizar la carne de la misma manera, es decir, carne blanca y carne roja? Lo más probable es que no lo harías. Entonces mi punto es que probablemente tampoco sea necesario categorizar la fruta por color.
En su lugar, algunos atributos están mejor representados de otras maneras. De hecho, en su forma más simple, podría registrarse como una columna en la tabla de "alimentos" etiquetada como "color". O bien, si se trata de un atributo muy común y se encuentra duplicando significativamente el valor, podría dividirse en una tabla separada denominada 'color' y correlacionarse con cada artículo alimenticio de una tercera tabla. Por supuesto, el enfoque más abstracto sería generalizar la tabla como 'etiquetas' e incluir cada color como una etiqueta individual que luego puede asignarse a cualquier artículo alimenticio. Luego, puede asignar cualquier número de etiquetas (colores) a cualquier cantidad de alimentos, lo que le proporciona una verdadera relación de muchos a muchos y también libera las designaciones de categoría para que sean más generales.
Sé que hay un debate continuo sobre si las etiquetas son categorías o categorías son etiquetas, etc., pero esta parece ser una instancia en la que podrían ser complementarios y crear un sistema más abstracto y robusto que sea más fácil de administrar.
Sí, he estado buscando una respuesta pero no encuentro nada definitivo sobre el tema. Estoy utilizando MySQL en este punto, ¿me encontraré con problemas para convertir a una base de datos no libre en el futuro con la duplicación de Apple? ¿O debería tratar de resolver este problema al no permitir el uso de múltiples padres en este punto y simplemente usar el enfoque del Conjunto anidado tal como está? ¿O hay otra forma de abordar este problema utilizando MySQL? – swisscheese
Al menos en el contexto de Oracle no se encontrará con ningún problema. El enfoque del conjunto anidado es bastante portátil porque usa construcciones SQL estándar. En el contexto general, no veo ningún mal con la duplicación de la manzana _reference_. Nunca utilicé los conjuntos anidados en mi práctica, aunque estoy familiarizado con ella. Pero estaría más preocupado por las modificaciones (agregar/eliminar/mover nodos) del árbol. En general son más lentos. También tenga en cuenta que esta no es una técnica estándar y los mantenedores de su solución pueden necesitar un comienzo difícil. –
Gracias por su ayuda con este problema. Si tiene la oportunidad y está dispuesto, ¿puede mirar mi pregunta sobre esto en http://stackoverflow.com/questions/5395463/data-modeling-modeling-categories-subcategories-in-mysql – swisscheese