2009-06-17 7 views
1

J'ai un panier dans lequel je dois garder une trace de stock, et cela comprend le stock avec des attributs. Par exemple:Comment puis-je structurer une table pour que le champ reste atomique?

shirt 
-- blue, small = 50 
-- blue, medium = 22 
-- blue, large = 53 
-- red, small = 15 
etc... 

Ces champs sont actuellement séparés par des virgules dans la base de données et les identificateurs seraient les suivants:

1,3 
1,4 
1,5 
2,3 

où chaque numéro représente un attribut spécifique (1 = bleu, 3 = faible). Le problème est que cela devient alors très difficile de travailler avec, car les données ne sont pas atomique dans la base de données, mais je ne peux pas penser à comment structurer la table, comme il pourrait y avoir une infinité de combinaisons d'éléments tels que:

blue, small, long-sleeved 

Quelqu'un peut-il suggérer un meilleur moyen de stocker cette information dans la base de données? J'ai pensé utiliser des tables de recherche, mais cela ne fonctionnerait pas en raison du nombre variable d'attributs.

+0

Quel est l'attribut que vous avez? je pense à la solution binaire chaque bit à attribuer –

+0

combien d'attribut vous avez? –

+0

Il pourrait potentiellement y avoir beaucoup, quel est le problème. Le nombre d'entre eux est arbitraire – xenon

Répondre

4

Tableau: shirt {shirt_id}

Tableau: ShirtAttributeDefinitions {attribute_id, attribute_description}

Tableau: ShirtAttribute {shirt_id, attribute_id}

cette façon, vous pouvez continuer à définir de nouvelles ShirtAttributes en ajoutant des enregistrements à la table: ShirtAttributeDefinitions.

Exemple:

vous avez deux chemises: {shirt_id: 1}, {shirt_id: 2}

vous avez cinq chemise attributs: {attribute_id: 1, attribute_description: bleu}, {attribute_id : 2, attribute_description: small}, {attribute_id: 3, description de l'attribut: ladies}, {attribute_id: 4, attribute_description: red}, {attribute_id: 5, attribute_description: men}

Maintenant votre première chemise est une petite bleue chemise, et le second est une chemise pour homme rouge. Ainsi votre table ShirtAttribute aura ces recrodes:

{ID_file: 1, attribut_id: 1}, {ID_file: 1, attribut_id: 2}, {ID_file: 1, attribut_id: 3}, {ID_file: 2, attribut_id: 4}, {ID_fille: 2, attribut_id: 5}

Bien que cette approche fonctionne, il est préférable de créer ces champs d'attributs de la table Shirt. De cette façon, vous pouvez vous assurer qu'une chemise n'a pas à la fois l'attribut 'homme' et 'femme'. Cette méthode est juste une approche sale qui est strictement conforme à votre question.

jrh.

+0

+1. C'est en fait le moyen le plus "propre" de faire cela dans un SGBDR - de nouveaux attributs peuvent être ajoutés plus tard sans modifications de schéma.Mais comme vous le dites, vous perdez malheureusement des opportunités pour imposer des contraintes. –

+0

en effet. Une application commune comme un panier n'a vraiment pas besoin de cette générosité ... ou alors je me sens. – jrharshath

+0

Quand vous dites "T-shirt" table vous référez-vous à la table des produits que la chemise était méchant à titre d'exemple? Il peut potentiellement y avoir plusieurs types de produits. – xenon

1

Qu'est-ce qui ne va pas avec un tableau d'attributs?

create table Attributes (
    Id int not null identity etc, 
    CartItemId int not null foreign-key etc, 
    Name nvarchar(32), 
    Value nvarchar(32) 
) 

?

+0

En effet, ce serait la façon dont je recommanderais. Bien sûr, cette méthode a une perte de générativité associée. – jrharshath

+0

Cela ne résout pas le problème de garder le stock pour plusieurs attributs. La table des attributs pourrait avoir "Small" & "Blue" mais je dois garder le stock pour une chemise "Small Blue". – xenon

+0

@ [xénon]: s'il vous plaît expliquer comment petit et bleu est différent de "petit bleu" –

Questions connexes