eコマースのためのpostgresqlデータベース設計

靴を見るだけで、靴という1つのエンティティがあります。サイズと色の2つの直接的な属性があります。これらの各属性のドメインは厳密に定義する必要があります。これは、それらのルックアップテーブルを示します。価格と数量の2つの間接的な属性がありますが、これらは靴自体よりもサイズ/色の各組み合わせの属性です。

これは、1つのエンティティテーブルを示唆しています。 2つのルックアップテーブル：サイズと色。および1つの三叉路テーブル：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 )
);

したがって、たとえば、組み合わせ（'Penny Loafer'、 '10 1/2'、'Tan'）には、特定の価格と数量があります。サイズ11タンには、10 1/2バーガンディと同様に、独自の価格と数量があります。

たとえば、（15、4、3、45.00、175）ではなく、テーブルを結合して結果を上記のように使いやすい形式で表示するビューをお勧めします。ビューのトリガーは、ビューを介したアプリケーションによるすべてのアクセスを許可する可能性があるため、アプリはデータの物理的なレイアウトに依存しません。このようなビューは非常に強力なツールであり、基盤となるデータとアプリ自体の堅牢性と保守性を大幅に向上させますが、十分に活用されていません。