petite question: Comment strong> devrait catégories de produits qui apparaissent dans plusieurs catégories de gérer? Est-ce une mauvaise pratique de le faire du tout Infos générales: strong>
Nous avons une base de données de produits avec des catégories aime ceci: p> Category
----------
CategoryID
CategoryName
CategoryTree
------------
CategoryTreeID
CategoryID
Lft
Rgt
4 Réponses :
Il peut bien être nécessaire pour une catégorie d'avoir plusieurs parents. Cependant, peu importe le parent que vous avez trouvé une catégorie sous, ses sous-catégories doivent rester les mêmes.
J'ai vu de vrais systèmes mis en œuvre précisément cette logique et a fonctionné bien.
éditer
Pour répondre à votre question, je ne pense pas que le modèle que je suggère est aussi restrictif que vous imaginez. Fondamentalement, une branche donnée de l'arbre peut être trouvée sous plus d'une branche parentale, mais partout où elle se trouve, elle a les mêmes enfants. Rien à propos de cela ne vous empêche de choisir des enfants d'une branche et de leur faire des enfants d'une autre.
Ainsi, par exemple, vous pouvez inclure la catégorie des colles sous les sources de bureau et les fournitures de loisirs, et si vous avez ajouté «Crazy Colle (suppositoire Edition)», il apparaîtrait dans les deux. Si vous avez des articles pouvant être regroupés de manière logique mais qu'il faut être séparé par leur utilisation, vous pouvez toujours le faire. Vous pourriez mettre de la mucilage et de la pâte dans la catégorie des adhésifs du passe-temps, qui passe sous la racine du passe-temps, mais pas sous la racine de bureau. Ou vous pouvez le faire et avoir simultanément une catégorie combinée utilisée en interne par vos acheteurs. Ce que vous ne pouvez pas faire, c'est oublier d'inclure ce nouveau type de colle dans toutes les catégories pertinentes une fois que vous l'avez ajoutée partout où il appartient à l'ontologie de votre métier d'entreprise.
En bref, vous perdez très peu avec cette restriction, mais gagnez un peu de structure pour éviter tout problème d'avoir à gérer chaque article individuellement.
éditer
En supposant que j'ai fait un cas convaincant pour le modèle lui-même, il reste-t-il de la question de la mise en œuvre. Il y a beaucoup d'options, mais voici une façon d'aller:
Il existe une table de catalogitem contenant une clé primaire synthétique, l'étiquette, la description / texte de détail en option, ainsi qu'un SKU optionnel (ou équivalent). Vous avez ensuite un catalogitemjoin beaucoup à plusieurs avec des identifiants enfants et parents, les deux côtés contraints au catalogitemtable.
Un élément qui apparaît comme un parent est une catégorie, il ne faut donc pas avoir de SKU. Un article qui n'apparaît que comme un enfant est un produit, il devrait donc avoir une SKU. C'est bien que tout article ait plus d'un parent; Cela signifie simplement que c'est dans plusieurs catégories. De même, il n'y a pas de problème avec plusieurs enfants par parent; Ce serait le cas typique d'une catégorie avec quelques produits. Cependant, étant donné l'identification d'une catégorie, ses enfants seront les mêmes, quels que soient la catégorie mère vous l'a conduit. L'autre contrainte est que vous voudrez éviter les boucles.
Merci Steven - Pouvez-vous clarifier pourquoi les sous-catégories doivent rester les mêmes? Dans mon exemple, la structure n'exige pas. Et il ne serait pas de sens de mettre du papier de construction sous fournitures de bureau. Donc, la solution serait d'attribuer des produits à une place dans l'arborescence de la catégorie plutôt que de l'ID de catégorie, ce qui rend la gestion plus de travail car je devrais affecter un produit aux deux cas de la catégorie de colle dans l'arborescence, mais fournit plus la flexibilité.
Cory, j'ai ajouté une section pour essayer de répondre à votre question. Est-ce que ça?
L'exemple le plus célèbre de ceci est Google Mail, où la classification est effectuée de cette façon. Google est célèbre pour la convivialité de leurs produits ...
Je pense que d'autres mots sont préférables au mot "Parent", qui suggèrent réellement une relation Xtoone ...
Peut-être que vous pourriez dire qu'un Cela mettrait en évidence un problème: si vous ne limitez pas le nombre de catégories et que vous affichez les catégories avec des sous-catégories, etc., vous pourriez vous retrouver avec:
La partie intéressante met en évidence le problème, puis imaginer une solution qui convient à l'utilisateur final. produit autant de catégories , la relation serait donc de nombreuses tomanies. Et seul l'affichage commence par des catégories pour atteindre les produits ...
Je ne vois rien de mal à cela aussi longtemps qu'il est vrai que TOUT COLLE est approprié pour les deux fournitures de bureau
Et si ce n'est pas? Comme un bâton d'enfants colle. Ce ne sont que des arts et de l'artisanat. Donc, vous êtes vraiment bloqué Créer une catégorie distincte, d'accord? Toute suggestion? J'ai du mal à décrire une situation où chaque produit de la catégorie serait applicable dans les deux endroits. Je ne suis pas sûr que l'un existe même.
Avec le modèle que vous avez, alors oui, vous auriez besoin de créer une catégorie distincte. Je suppose que vos deux options, je suppose, soit de séparer la catégorisation d'affichage à partir de la catégorisation Taxonmique (avec un autre attribut) ou de faire connaître vos arbres de catégorie des arbres distincts de la racine à la feuille, puis d'associer le produit à ces arbres. (Je n'ai pas totalement pensé à ce que cela puisse savoir à quel point il est évolutif)
Jacob, je aurais dû lire votre réponse avant de répondre à Cory, comme vous couvrir une grande partie du même terrain, et souvent plus économique.
Qu'est-ce que vous avez est un bon moyen, mais pourquoi ne pas simplifier la 2e table comme si:
id Nom
id Catégorieid Sous-catégorieID
Cependant, pour l'avenir, je me méfierais de partager des catégories d'enfants entre les deux catégories racines. Il est parfois préférable de créer une catégorisation unique de produits de cohérence, ce qui est plus facile à gérer pour vous et potentiellement plus facile à naviguer pour le client. Sinon, vous avez le problème que si vous êtes sur la page de colle provenant de fournitures de bureau, puis-tu montrer l'autre chemin aussi? Sinon, vous aurez deux pages identiques, à l'exception du chemin, qui est un problème pour le référencement. Si vous le faites, l'utilisateur peut être confus.
Excellent point Eulerfx. Nous avons eu juste ce problème, qui est l'une des nombreuses raisons que je pose cela.
@eulerfx, pourriez-vous s'il vous plaît dites davantage sur la manière dont disposer de deux pages avec des contenus identiques sauf pour un parent différent de la hiérarchie pourrait causer des problèmes de référencement?
Je viens de remarquer que votre suggestion de table de sous-catégorie décrivait le modèle de adjacence. Bien que je sois d'accord, il est une fortune plus simple de comprendre initialement et de faire des inserts et des mises à jour, les performances du modèle de jeu imbriqué sont beaucoup supérieures sur Selects - qui sur une structure de catégorie de produit, est de 99% de notre trafic. De plus, interroger un ensemble imbriqué est beaucoup plus simple. Le modèle de adjacence nécessite une jointure à chaque niveau de l'arbre qui devient manifeste sur de grands arbres.
MS SQL Server a CTE, qui permet une récursive efficace, et je sais que Oracle a quelque chose au moins aussi puissant, alors n'écrivez pas une bonne solution basée sur des problèmes de performances possibles. J'ajouterais également que l'affichage d'un catalogue est un cas prototypé où la mise en cache des pages Web elles-mêmes peut être nécessaire sur un site de charge élevé.
Bon points Steven, bien que l'application en question soit sur MySQL et je suis au courant d'aucune fonctionnalité récursive équivalente. Et honnêtement, c'est la simplicité et l'évolutivité d'interroger un ensemble imbriqué que je trouve le plus attrayant sur le modèle d'adjacence.
Cory, je n'avais pas compris que MySQL avait un écart de fonctionnalité ici, mais jetez un coup d'œil à cela: jgeewax.wardpress.com/2006/07/17/...
Cela pourrait être un problème de référencement car, par exemple, Googlebot découvrira ce contenu similaire sur les deux pages et diminuera probablement le classement de ces pages. Il le dit dans leur docs en ligne. De plus, si vous avez un compte WebMasters sur Google, il affichera les messages lorsque GoogleBot découvre un contenu similaire.
Je penserais que vous perdriez au classement sur chacun des doublons, mais je ne sais pas que vous perdriez dans son ensemble. Il n'y a aucune raison que deux copies devraient être autorisées à compter pour plus d'une.