Wenn Sie sich nur Schuhe ansehen, haben Sie eine Einheit:Schuhe. Es hat zwei direkte Attribute:Größe und Farbe. Die Domäne jedes dieser Attribute muss streng definiert werden, was Nachschlagetabellen für sie anzeigt. Es gibt zwei indirekte Attribute, Preis und Menge, aber dies sind eher Attribute der jeweiligen Größen-/Farbkombination als eines Schuhs selbst.
Dies schlägt eine Entitätstabelle vor:Schuhe; zwei Nachschlagetabellen:Größen und Farben; und eine Drei-Wege-Schnitttabelle: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 )
);
So hat beispielsweise die Kombination ('Penny Loafer', '10 1/2', 'Tan') einen bestimmten Preis und eine bestimmte Menge zur Hand. Die Größe 11 Tan hat einen eigenen Preis und eine eigene Menge, ebenso wie die 10 1/2 Burgandy.
Ich würde eine Ansicht empfehlen, die die Tabellen verbindet und die Ergebnisse in einer brauchbareren Form darstellt, wie oben gezeigt, anstatt beispielsweise (15, 4, 3, 45,00, 175). Auslöser für die Ansicht könnten den gesamten Zugriff durch die Anwendung über die Ansicht zulassen, sodass die App unabhängig vom physischen Layout der Daten bleibt. Solche Ansichten sind ein äußerst leistungsfähiges Werkzeug, das erheblich zur Robustheit und Wartbarkeit der zugrunde liegenden Daten und der App selbst beiträgt, aber leider zu wenig genutzt wird.
