Será permitindo uma categoria para ter vários pais fazem sentido? Existem alternativas?

Question

pergunta curta: Como deve categorias de produtos que aparecem em várias categorias ser gerenciado? É uma prática ruim para fazê-lo em tudo?

info fundo Temos um banco de dados de produto com categorias gosta deste:

Products

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


  -Office Supplies
    -Glue
    -Paper Clips

Note que cola e grampos de papel são atribuídos a ambas as categorias. E embora eles aparecem em dois pontos diferentes nesta árvore de categorias, têm o mesmo ID da categoria no banco de dados . Por quê? Duas razões:

1. As categorias são atributos atribuído - por exemplo, um clipe de papel poderia ter um peso, um material, uma cor, etc.
2. Produtos atribuídos à categoria de cola são exibidas em artes e ofícios e material de escritório. Que é de se esperar -. Eles são o mesmo ID da categoria real no banco de dados

Isso nos permite gerenciar uma única categoria e é atributos e produtos atribuídos, mas colocá-lo em vários lugares dentro da árvore de categorias.

Estamos usando a aninhado modelo de conjunto , de modo que o db estruturar usamos para apoiar esta é:

Category
----------
CategoryID
CategoryName


CategoryTree
------------
CategoryTreeID
CategoryID
Lft
Rgt

Portanto, há uma 1:. M entre Categoria e CategoryTree porque pode haver várias instâncias de uma determinada categoria dentro da árvore de categorias

Existe uma maneira mais simples de modelar essa que permitiria uma categoria de produto para exibição em várias categorias?

Answer 1

Eu não vejo nada de errado com isso, desde que seja verdade que todas Glue é apropriado tanto para Escritório e materiais de artesanato.

Answer 2

O que você tem é uma boa maneira, embora porque não simplificar a segunda mesa assim:

Categoria

ID Nome

Sub

ID Categoria ID SubCategoryID

Embora para o futuro eu gostaria cuidado de compartilhar categorias filho entre as duas categorias de raiz. Às vezes é melhor para criar uma categorização única de produtos para a consistência, o que é mais fácil de gerir para você e potencialmente mais fácil de navegar para o cliente. Caso contrário, você tem a questão de que se você estiver na página de cola vindo de material de escritório, em seguida, fazê-lo mostrar o outro caminho também? Se não, você terá duas páginas idênticas, exceto para o caminho, que é um problema para SEO. Se o fizer, então o usuário pode ficar confuso.

Answer 3

O exemplo mais famoso é o Google Mail, em que a classificação é feita desta forma. Google é famoso para a usabilidade de seus produtos ...

Eu acredito que outras palavras são preferíveis para a palavra "pai", que realmente sugerem única relação XToOne ...

Talvez você poderia dizer que um Product como muitos Categories, de modo que o relacionamento seria ManyToMany. E somente a exibição que começa com categorias para alcançar os produtos ...

---

Este gostaria de destacar um problema: se você não limitar o número de categorias, e você exibir as categorias com sub-categorias e assim por diante, você pode acabar com:

• uma lista enorme categorias e produtos, com muitas muitas duplicações
• a grande profundidade (provavelmente ilegível)

A parte interessante é destacar o problema, então a imaginar uma solução que é bom para o usuário final.

Answer 4

Pode muito bem ser necessária para uma categoria de ter vários pais. No entanto, não importa o pai que você encontrou uma categoria abaixo, suas subcategorias deve permanecer o mesmo.

Eu vi sistemas reais que implementaram precisamente essa lógica e funcionou bem.

editar

Para responder à sua pergunta, eu não acho que o modelo que eu estou sugerindo é tão restritiva quanto você imagina. Basicamente, um determinado ramo da árvore pode ser encontrada em mais de uma ramificação pai, mas onde quer que seja encontrado, ele tem as mesmas crianças. Nada sobre isso evita que você cherry-picking algumas crianças de um mesmo ramo e também tornando-os filhos de outro.

Assim, por exemplo, você poderia incluir a categoria colas sob as duas fontes de escritório e suprimentos de hobby, e se você adicionou "Crazy Glue (Supositório Edition)" sob colas, ele iria mostrar-se em ambos. Se você tem itens que podem ser agrupados logicamente, mas precisam ser separadas por seu uso, você ainda pode fazer isso. Você pode colocar mucilagem e cole na categoria de adesivos passatempo, que vai na raiz do passatempo, mas não sob a raiz escritório. Ou você poderia fazer isso e ao mesmo tempo ter uma categoria combinado que é usado internamente por seus compradores. O que você não pode fazer é se esqueça de incluir esse novo tipo de cola em todas as categorias relevantes, uma vez que você adicionou-lo onde ele pertence em seu modelo de negócio ontologia.

Em suma, você perde muito pouco com essa restrição, mas ganhar um pouco de estrutura para ajudar a evitar o problema de ter que gerenciar cada item individualmente.

editar

Supondo que eu fiz um caso convincente para o próprio modelo, ainda há a questão da aplicação. Existem muitas opções, mas aqui está um caminho a percorrer:

Há uma mesa CatalogItem contendo uma chave sintético primário, o rótulo, texto de descrição / detalhe opcional, e um SKU opcional (ou equivalente). Você então tem uma relação muitos-para-muitos CatalogItemJoin com a criança eo pai ID de ambos os lados, constrangidos a CatalogItemTable.

Um item que aparece como um pai é uma categoria, por isso não deve ter um SKU. Um item que aparece apenas como uma criança é um produto, por isso deve ter uma SKU. É bom para qualquer item de ter mais de um pai; Isso só significa que é em várias categorias. Da mesma forma, não há nenhum problema com vários filhos por pai; que seria o caso típico de uma categoria com alguns produtos na mesma. No entanto, dada de uma categoria ID, seus filhos será o mesmo, independentemente do que categoria pai o levou lá. A outra restrição é que você vai querer evitar loops.