J'ai une question pour la façon de concevoir quelques tables dans ma base de données. J'ai une table pour suivre des catégories et une pour sous-catégories:
TABLE Product
SubcategoryID INT -- should this be subcategory?
6 Réponses :
Si les catégories et les sous-catégories ont les mêmes attributs, puis réduisez-les dans une table.
Si une catégorie «sous» peut appartenir à plus d'une catégorie «parent», ajoutez une classe de liaison, sinon ajoutez une seule colonne à pointer vers un parent.
E.g. Si vous avez des appareils électroniques> Télévision, pouvez-vous aussi avoir des divertissements> TV? c.
Votre autre table doit faire référence à la catégorie_id (note - non parent_category_id)
htth
J'aimerais qu'ils soient séparés mais je ne suis pas sûr qu'ils doivent être. Au moins, je dois pouvoir récupérer séparément des catégories "de haut niveau".
Dans ce schéma, les catégories de haut niveau sont définies comme toutes les catégories qui n'ont pas de catégories parent. Cela me semble un design propre.
Tant que les sous-catégories ne se répètent jamais dans une catégorie différente, et surtout s'ils ont des attributs différents, votre méthode proposée est bonne.
Le seul problème peut venir lorsque vous ajoutez / éditer des produits, et vous n'avez pas de champ pour la catégorie, même si vous souhaitez probablement un contrôle dans lequel l'utilisateur peut modifier la catégorie.
avoir deux tables distinctes pour Si vous conservez la façon dont il est limité à une catégorie> Scénario de sous-catégorie, comme dans vous ne pouvez pas avoir de sous-catégories de sous-catégories.
Si vous les faites dans une table, vous avez besoin d'une colonne pour Catégories et sous-catégories dépend de votre situation.
parentid . Si une catégorie est la plus grande, il aura un parentid de 0. Si vous souhaitez autoriser des sous-catégories de sous-catégorie illimitée, par exemple Electronics> Media enregistrable, Blueray, 4GB Vous devrez utiliser une programmation récursive pour les afficher.
Cela dépend de vos besoins. Si chaque produit est lié à pas plus d'une sous-catégorie, vous devez avoir sous-catégorieID dans les produits. Il n'est pas nécessaire d'ajouter également de la catégorie identité.
D'autres scénarios nécessitant un modèle différent, un produit pourrait être associé directement à une catégorie au lieu d'une sous-catégorie ou qu'un produit pourrait être lié à plus d'une sous-catégorie ou qu'une sous-catégorie est liée à plus d'une catégorie. < / p>
Je pense que le niveau "Catégorie" est comme un niveau super auquel aucun produit ne doit être lié directement, il devrait toujours y avoir une sous-catégorie pour lier les produits à.
Attachez des étiquettes aux produits au lieu d'une hiérarchie de catégorie. Il est beaucoup plus flexible.
create table product (id, name,...) create table tag (id, name, description) create table product_tag (product_id, tag_id)
Les étiquettes de produits seront-elles aidées à troisième et troisième niveau de catégorie?
Votre conception est appropriée. Je suis un gars de base de données devenu développeur, je peux donc comprendre l'inclinaison d'avoir une catégorie et une sous-catégorie dans une table, mais vous ne pouvez jamais vous tromper par Kiss.
sauf si une performance extrême ou une hiérarchie infinie est une exigence (je devine pas), vous êtes prêt à partir.
Si être capable d'associer plusieurs sous-catégories avec un produit est une exigence, à @ Mikael's Point, vous auriez besoin d'une configuration comme celle-ci qui crée un nombre - à de nombreuses relations via une table de jointure / intersect, produit_subcategory: espère que cela aide ... Eric Tarasoff
Cela me permet-il de faire plusieurs sous-catégories?
Cela dit qu'un produit peut avoir plusieurs sous-catégories (et inversement) ... mais une sous-catégorie est liée à une seule catégorie.
Même lorsqu'une sous-catégorie se répète, il n'est pas nécessaire d'avoir les mêmes attributs. Un M-M n'est pas vraiment pratique. Une table auto-jointe avec une table d'attributs distincte est plus susceptible de couvrir plus de cas.
@Erictarasoff Que devrais-je modifier si je dois avoir plusieurs catégories et plusieurs sous-catégories?
Votre approche fonctionne bien et est simple (requêtes simples) pour un scénario particulier (catégories de sous-catégories), mais n'est pas très extensible, si vous avez d'autres exigences, si vous avez d'autres exigences, comme plus de niveaux de sous-catégories dans des sous-catégories, accédez à la table unique en ajoutant un parent_id