progettazione di database postgresql per l'e-commerce

Solo guardando le scarpe, hai un'entità:le scarpe. Ha due attributi diretti:taglia e colore. Il dominio di ciascuno di questi attributi deve essere rigorosamente definito, il che indica le relative tabelle di ricerca. Ci sono due attributi indiretti, prezzo e quantità, ma questi sono attributi più di ogni combinazione di taglia/colore che di una scarpa stessa.

Ciò suggerisce una tabella di entità:Scarpe; due tabelle di ricerca:Taglie e Colori; e una tabella di intersezione a tre vie: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 )
);

Così, ad esempio, la combinazione ("Penny Loafer", "10 1/2", "Tan") avrà un prezzo e una quantità particolari a portata di mano. La taglia 11 Tan avrà il suo prezzo e la sua quantità così come la 10 1/2 Borgogna.

Consiglierei una vista che unisca le tabelle e presenti i risultati in una forma più utilizzabile come mostrato sopra piuttosto che, ad esempio, (15, 4, 3, 45.00, 175). I trigger sulla vista potrebbero consentire tutto l'accesso da parte dell'applicazione attraverso la vista in modo che l'app rimanga indipendente dal layout fisico dei dati. Tali visualizzazioni sono uno strumento estremamente potente che aumenta in modo significativo la robustezza e la manutenibilità dei dati sottostanti e dell'app stessa, ma che sono purtroppo sottoutilizzati.