Comment puis-je créer une hiérarchie de type "eBay" de catégories et de sous-catégories?

Je construis un site web d'annonces classées en utilisant les formulaires web asp.net et linq-to-sql.

Les articles en vente doivent être catégorisés de manière hiérarchique, cependant, un article individuel peut être dans plusieurs catégories enfants.

Pour un exemple, jetez un oeil à cette batterie sur eBay. Notez qu'il y a deux chapelures:

Son et image> Piles multifonctions et alimentation> Piles rechargeables
et bien comme:
Informatique / Tablettes et réseaux> Accessoires pour ordinateurs portables et de bureau> Batteries pour ordinateurs portables

En plus d'un article appartenant à plusieurs catégories, une catégorie peut avoir plus d'un parent, par exemple lorsque vous naviguez dans les catégories "Sound & Vision> Batteries" ou "Electronics> Batteries", il faut voir exactement les mêmes sous-catégories de Batteries dans les deux cas (par exemple Rechargeable ou non rechargeable, etc.).

Je ne sais pas comment commencer à structurer les tables de la database, et encore less les interroger à partir du site Web, de sorte que toute aide ou orientation serait très appréciée.

J'ai examiné des articles tels que Stocker des données hiérarchiques dans une database , mais je ne pense pas que cela s'appliquerait dans mon cas en raison de la nature plusieurs-à-plusieurs des éléments et des catégories.

Merci.

Récemment, j'ai fait face au même problème et je stocke des catégories dans une grande table comme celle-ci

CATEGORIES ------------------ Id Text ParentId 

Jusqu'à présent, cela fonctionne pour moi, mais je serais curieux de savoir si de meilleures réponses se présentent

Pour votre exemple, vous pouvez séparer les parents dans une table distincte, car vous voulez être en mesure d'avoir une relation plusieurs-à-plusieurs

Tu pourrais le faire comme ça

 CATEGORIES ---------------- Id Text CATEGORY_PARENTS ---------------- ID ParentId 

Habituellement, le moyen le plus efficace consiste à décomposer datatables au niveau le plus bas possible et à éviter autant que possible la redondance des données. En bref, brisez les tables autant que possible tout en conservant datatables associées dans un groupe (ou une table ici) et en vous assurant que vous ne répétez pas de données réelles dans les tables (en créant des tables de jointure sur les ID).

Je ne suis pas sûr combien vous êtes prêt à modifier votre schéma de database ou comment votre schéma actuel est construit, mais une solution peut être que vous créez une table pour stocker toutes les grandes catégories (appelons le tableau A), une autre table pour le deuxième niveau catégories (tableau B) et une autre pour le niveau le plus bas des catégories (tableau C).

Ensuite, vous pouvez créer une nouvelle table (table D) pour attacher la table A et la table B. Donc maintenant vos catégories principales et sous-catégories sont connectées.

Créer une sous-catégorie pour une sous-catégorie est un défi. Vous pouvez surmonter ce problème en ajoutant un champ supplémentaire à la table D indiquant si l'élément en cours est un 'sous-élément secondaire' (je sais, mon sens de nommage suce: P) ou non. c'est-à-dire si le champ indicateur est 0, c'est un sous-chat, sinon la valeur du champ indicateur est l'id du sous-élément parent. C'est une sorte de soi-même.

Pour un article appartenant à plusieurs catégories, créez une autre table (table E) qui connecte la table d'objects et la table D. Ici vous connectez 'itemID' avec 'subcatID'. c'est-à-dire que si l'ID d'article de la batterie est de 10, le sous-ID de la batterie rechargeable est de 5 et le sous-ID de la batterie de l'ordinateur portable est de 7, alors vous faites deux rangées dans le tableau E

 itemID subcatID 10 5 10 7 

Lorsque vous effectuez une search, searchz tous les 10 et vous aurez toutes les catégories.

Encore une fois, c'est une solution possible. Vous pouvez également utiliser le schéma en écanvas mais c'est particulièrement efficace pour l'entreposage de données. Si les numéros de vos catégories sont fixes (vous n'aurez que trois catégories de niveaux, etc.), vous pouvez utiliser des tables de style en cascade (le tableau A est le chat principal, le tableau B le chat sub et le tableau C le dernier .). Cela rendra vos requêtes un peu longues mais simples. Je ne fais que commencer dans le champ de la database afin de déplacer / tagging cette question avec des balises de database vous obtiendrez probablement une meilleure réponse.

Bonne chance!

Merci à @ bhrugesh-patel et @ andrew-walters pour avoir tenté de répondre à ma question. Cependant, après d'autres searchs, il apparaît que la hiérarchie décrite ci-dessus s'appelle un Directed Acyclic Graph (DAG), c'est-à-dire presque un tree mais avec une différence majeure: vous pouvez atteindre le même nœud par des paths différents.

Les bases de données charts comme Neo4j sont conçues pour stocker des structures comme les DAG, mais comme je suis bloqué avec une database relationnelle (SQL Server), je vais essayer d'implémenter la solution mentionnée dans cet article: Un model pour représenter des graphes acycliques dirigés ( DAG) sur les bases de données SQL .

FYI: Une autre question sur SO aborde également ce sujet plus en détail.