diseño de base de datos postgresql para comercio electrónico

Solo mirando los zapatos, tienes una entidad:zapatos. Tiene dos atributos directos:tamaño y color. El dominio de cada uno de estos atributos debe estar estrictamente definido, lo que indica tablas de búsqueda para ellos. Hay dos atributos indirectos, precio y cantidad, pero estos son atributos más de cada combinación de talla/color que de un zapato en sí.

Esto sugiere una tabla de entidad:Zapatos; dos tablas de consulta:Tallas y Colores; y una mesa de intersección de tres vías: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 )
);

Así, por ejemplo, la combinación ('Penny Loafer', '10 1/2', 'Tan') tendrá a mano un precio y una cantidad determinados. La talla 11 Tan tendrá su propio precio y cantidad al igual que la 10 1/2 Burgandy.

Recomendaría una vista que una las tablas y presente los resultados en una forma más útil, como se muestra arriba, en lugar de, por ejemplo, (15, 4, 3, 45,00, 175). Los disparadores en la vista podrían permitir todo el acceso de la aplicación a través de la vista para que la aplicación permanezca independiente del diseño físico de los datos. Tales vistas son una herramienta extremadamente poderosa que aumenta significativamente la solidez y la capacidad de mantenimiento de los datos subyacentes y de la propia aplicación, pero lamentablemente se subutilizan.