Rien qu'en regardant les chaussures, vous avez une entité :les chaussures. Il a deux attributs directs :la taille et la couleur. Le domaine de chacun de ces attributs doit être strictement défini, ce qui indique des tables de recherche pour eux. Il y a deux attributs indirects, le prix et la quantité, mais ce sont plus des attributs de chaque combinaison de taille/couleur que d'une chaussure elle-même.
Cela suggère une table d'entité :Chaussures; deux tables de correspondance :Tailles et Couleurs; et une table d'intersection à trois entrées :ShoeStyles :
create table ShoeStyles(
ShoeID int not null,
SizeID smallint not null,
ColorID char( 1 ) not null,
Price currency,
Qty int not null default 0,
constraint FK_ShoeStyles_Shoe foreign key references Shoes( ID ),
constraint FK_ShoeStyles_Size foreign key references Sizes( ID ),
constraint FK_ShoeStyles_Color foreign key references Colors( ID ),
constraint PK_ShoeStyles primary key( ShoeID, SizeID, ColorID )
);
Ainsi, par exemple, la combinaison ('Penny Loafer', '10 1/2', 'Tan') aura un prix et une quantité particuliers en main. La taille 11 Tan aura son propre prix et sa propre quantité, tout comme la 10 1/2 Burgandy.
Je recommanderais une vue qui joint les tables et présente les résultats sous une forme plus utilisable comme indiqué ci-dessus plutôt que, disons, (15, 4, 3, 45.00, 175). Les déclencheurs sur la vue pourraient autoriser tous les accès par l'application via la vue afin que l'application reste indépendante de la disposition physique des données. Ces vues sont un outil extrêmement puissant qui ajoute de manière significative à la robustesse et à la maintenabilité des données sous-jacentes et de l'application elle-même, mais qui sont terriblement sous-utilisées.
