database - mysql hierarchical data

¿Permitir que una categoría tenga múltiples padres tiene sentido? ¿Hay alternativas? (4)

Pregunta breve: ¿Cómo deben gestionarse las categorías de productos que aparecen bajo múltiples categorías? ¿Es una mala práctica hacerlo en absoluto?

Información de fondo: Tenemos una base de datos de productos con categorías como esta:

Products -Arts and Crafts Supplies -Glue -Paper Clips -Construction Paper -Office Supplies -Glue -Paper Clips

Tenga en cuenta que el pegamento y los clips están asignados a ambas categorías. Y aunque aparecen en dos lugares diferentes en este árbol de categoría, tienen la misma ID de categoría en la base de datos . ¿Por qué? Dos razones:

Las categorías tienen atributos asignados, por ejemplo, un clip puede tener un peso, un material, un color, etc.
Los productos asignados a la categoría de pegamento se muestran en Artes y oficios y en Suministros de oficina. Lo que es de esperar, son la misma identificación de categoría real en la base de datos.

Esto nos permite administrar una sola categoría y sus atributos y productos asignados, pero la colocamos en varios lugares dentro del árbol de categorías.

Estamos utilizando el modelo de conjunto anidado , por lo que la estructura de db que usamos para respaldar esto es:

Category ---------- CategoryID CategoryName CategoryTree ------------ CategoryTreeID CategoryID Lft Rgt

Entonces, hay un 1: M entre Category y Category Tree porque puede haber múltiples instancias de una categoría dada dentro del árbol de categorías.

¿Hay alguna manera más sencilla de modelar esto que permita que una categoría de producto se muestre en múltiples categorías?

El ejemplo más famoso de esto es Google Mail, donde la clasificación se hace de esta manera. Google es famoso por la usabilidad de sus productos ...

Creo que otras palabras son preferibles a la palabra "padre", que en realidad solo sugieren una relación XToOne ...

Tal vez podría decir que un Product tantas Categories , por lo que la relación sería ManyToMany. Y solo la pantalla comenzaría con Categorías para llegar a los Productos ...

Esto resaltaría un problema: si no limita el número de categorías, y muestra las categorías con subcategorías, etc., podría terminar con:

una gran lista de categorías y productos, con muchas muchas duplicaciones
una gran profundidad (probablemente ilegible)

La parte interesante es resaltar el problema, luego imaginar una solución que esté bien para el usuario final.

Lo que tienes es una buena manera, aunque ¿por qué no simplificar la 2da mesa así:

Categoría

Nombre de identificación

Subcategoría

ID CategoryID SubCategoryID

Aunque para el futuro me guardaría de compartir categorías para niños entre las dos categorías de raíz. A veces es mejor crear una categorización única de los productos para mantener la consistencia, que es más fácil de administrar para usted y potencialmente más fácil de navegar para el cliente. De lo contrario, tiene el problema de que si está en la página de pegamento procedente de suministros de oficina, ¿muestra la otra ruta también? Si no, tendrá dos páginas idénticas, a excepción de la ruta, que es un problema para SEO. Si lo haces, entonces el usuario puede confundirse.

No veo nada de malo en esto, siempre y cuando sea cierto que todo el pegamento es apropiado tanto para suministros de oficina como artesanales.

Puede ser necesario que una categoría tenga múltiples padres. Sin embargo, independientemente del padre con el que encuentre una categoría, sus subcategorías deben seguir siendo las mismas.

He visto sistemas reales que implementaron precisamente esta lógica y funcionaron bien.

editar

Para responder a su pregunta, no creo que el modelo que estoy sugiriendo sea tan restrictivo como usted imagina. Básicamente, una rama dada del árbol se puede encontrar en más de una sucursal principal, pero donde sea que se encuentre, tiene los mismos hijos. Nada de esto le impide seleccionar a algunos niños de una rama y también hacerlos hijos de otra.

Entonces, por ejemplo, podría incluir la categoría de pegamentos tanto en suministros de oficina como en artículos para aficionados, y si agregaba "Crazy Glue (Suppository Edition)" debajo de pegamentos, aparecería en ambos. Si tiene elementos que pueden agruparse lógicamente pero deben separarse por su uso, aún puede hacerlo. Puede poner mucílagos y pegarlos dentro de la categoría de adhesivos para pasatiempos, que se encuentra debajo de la raíz de la afición, pero no debajo de la raíz de la oficina. O puede hacerlo y, al mismo tiempo, tener una categoría combinada que sus compradores usan internamente. Lo que no puede hacer es olvidarse de incluir ese nuevo tipo de pegamento en todas las categorías relevantes una vez que lo haya agregado a donde pertenezca en su ontología de modelo de negocio.

En resumen, pierde muy poco con esta restricción, pero gana un poco de estructura para ayudar a evitar el problema de tener que administrar cada elemento individualmente.

editar

Suponiendo que he hecho un caso convincente para el modelo en sí, todavía existe el problema de la implementación. Hay muchas opciones, pero esta es una forma de hacerlo:

Hay una tabla CatalogItem que contiene una clave primaria sintética, la etiqueta, descripción / texto de detalle opcional y una SKU opcional (o equivalente). A continuación, tiene un CatalogItemJoin muchos-a-muchos con identificadores secundarios y secundarios, ambos lados restringidos a CatalogItemTable.

Un elemento que aparece como padre es una categoría, por lo que no debe tener un SKU. Un artículo que aparece solo como un niño es un producto, por lo que debe tener un SKU. Está bien que cualquier artículo tenga más de un padre; eso solo significa que está en múltiples categorías. Del mismo modo, no hay problema con varios hijos por padre; ese sería el caso típico de una categoría con algunos productos. Sin embargo, dada la identificación de una categoría, sus hijos serán los mismos, independientemente de la categoría de padres que lo haya llevado allí. La otra restricción es que querrás evitar los bucles.