电子商务的postgresql数据库设计

Question

我必须为服装和鞋类电子商务网站设计数据库，
我不确定我对未来的 postgresql 查询使用是否正确？

示例产品可能是这样的：

(name) a shoes >  (size) 36  > (color) red > (price) 100 > (qty) 2    
(name) a shoes >  (size) 37  > (color) red > (price) 300 > (qty) 4  
(name) a shoes >  (size) 38  > (color) red > (price) 500 > (qty) 4  

(name) b shoes >  (size) 36  > (color) green > (price) 200 > (qty) 6  
...  



(name) a top >  (size) xs  > (color) purple > (price) 300 > (qty) 2  
...  

(name) a pants >  (size) 100-120cm  > (color) pink > (price) 100 > (qty) 2  
...  
(name) b pants >  (size) s  > (color) pink > (price) 100 > (qty) 2

尺寸并不总是 sml 或 n-n cm... 可以是来自项目制造商的任何字符串，所以我将列作为输入保留一些文本。

并且我将颜色 (product_size_color) 价格 (product_size_color_price) 和数量 (product_size_color_price_quantity) 分开，因为该网站是多语言的，所以以后我必须创建另一个 table 喜欢 product_size_color_jp, product_size_color_price_jp ...

欢迎提出任何建议..

table: product_base

primary: 
product_id

column:
product_id SERIAL NOT NULL,
product_name varchar,
product_introduction varchar,
product_description varchar,
active bit NOT NULL,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp

table: product_size

primary: 
product_size_id

column:
product_size_id SERIAL NOT NULL,
product_id integer NOT NULL, FOREIGN KEY (product_id) REFERENCES product_base (product_id) ON DELETE CASCADE
product_size_name varchar,
product_size_description varchar,
active bit NOT NULL,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp

table: product_size_颜色

primary:
product_size_color_id

column:
product_size_color_id SERIAL NOT NULL,
product_size_id integer NOT NULL, FOREIGN KEY (product_size_id) REFERENCES product_size (product_size_id) ON DELETE CASCADE
product_size_color_rgb_code_r integer,
product_size_color_rgb_code_g integer,
product_size_color_rgb_code_b integer,
product_size_color_name varchar,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp

table: product_size_color_price

primary: 
product_size_color_price_id

column:
product_size_color_price_id SERIAL NOT NULL,
product_size_color_id integer NOT NULL, FOREIGN KEY (product_size_color_id) REFERENCES product_size_color (product_size_color_id) ON DELETE CASCADE
product_size_color_price integer,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp

table: product_size_color_price_quantity

primary: 
product_size_color_price_quantity_id

column:
product_size_color_price_quantity_id SERIAL NOT NULL,
product_size_color_price_id integer NOT NULL, FOREIGN KEY (product_size_color_price_id) REFERENCES product_size_color_price (product_size_color_price_id) ON DELETE CASCADE
product_size_color_price_quantity integer,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp

更新

table:
product_base
primary:
product_id
column:
product_id SERIAL NOT NULL,
name varchar,
introduction varchar,
description varchar,
size_name varchar,
size_description varchar,
active bit NOT NULL,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp


table:
product_color
primary:
product_color_id
column:
product_color_id SERIAL NOT NULL,
product_id integer NOT NULL, FOREIGN KEY (product_id) REFERENCES product_base (product_id) ON DELETE CASCADE
color_rgb_code_r integer,
color_rgb_code_g integer,
color_rgb_code_b integer,
color_name varchar,
active bit NOT NULL,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp


table:
product_color_price
primary:
product_color_price_id
column:
product_color_price_id SERIAL NOT NULL,
product_color_id integer NOT NULL, FOREIGN KEY (product_color_id) REFERENCES product_color (product_color_id) ON DELETE CASCADE
price integer,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp


table:
product_color_quantity
primary:
product_color_quantity_id
column:
product_color_quantity_id SERIAL NOT NULL,
product_color_id integer NOT NULL, FOREIGN KEY (product_color_id) REFERENCES product_color (product_color_id) ON DELETE CASCADE
quantity integer,
create_by_user_id integer,
create_date timestamp,
modified_by_user_id integer,
modified_date timestamp

Answer 1

单看鞋子，就有一个实体：鞋子。它有两个直接属性：大小和颜色。这些属性中的每一个的域都必须严格定义，这表明它们的查找 tables。有两个间接属性，价格和数量，但这些是 size/color 每种组合的属性，而不是鞋子本身的属性。

这表明一个实体 table：鞋子；两次查找 tables：尺寸和颜色；和一个三向交叉路口 table：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 Tan 尺码和 10 1/2 Burgandy 尺码都有自己的价格和数量。

我会推荐一个连接 table 的视图，并以如上所示的更有用的形式显示结果，而不是说 (15, 4, 3, 45.00, 175)。视图上的触发器可以允许应用程序通过视图进行所有访问，因此应用程序仍然不知道数据的物理布局。这样的视图是一个非常强大的工具，它显着增加了底层数据和应用程序本身的稳健性和可维护性，但不幸的是，它们没有得到充分利用。

Answer 2

你的"chaining"很奇怪。你似乎有什么误解。您认为 table 存在的原因是什么？还是一个id属性？您似乎不了解关系设计的基础知识：每个基 table 都包含满足某些关于应用程序情况的特定参数化语句的行，这称为谓词。查询请求满足其自身谓词的行，该谓词是条件和基本 table 谓词的组合。我们选择base base table 谓词足以描述应用场景。请参阅的部分 "Educate yourself about database design"。

您需要为每种产品、尺寸和颜色提供基础/_base table，提供特定事物的特定信息。如果每个 table 的名称都是唯一的，那么您 不需要 ID。尽管您可能希望 ID 作为您的数据库所代表的系统中的人员的唯一标识符。

接下来您可能只需要一个包含产品、尺码、颜色、价格和数量列的 table。不是你的 product_size_color_price_quantity table 具有越来越长的列集的 ID。但是你没有清楚地解释清楚某行何时进入或离开table。即给出其谓词。考虑到它的谓词以及可能出现的应用情况，您还没有清楚地解释对 table 适用的后续限制。您的示例数据没有提供足够的信息。

我们是否拆分 5-way table 取决于它的谓词和限制。例如，如果价格仅取决于产品，那么您应该将新的 product_size_color_price_quantity table 替换为 product_size_color_quantity 和 product_id_price。这种将 tables 替换为诸如“... AND ...”之类的语句的想法被两个或更多个每个替换为“...”的语句的想法称为规范化。我们需要了解规范化的主要 table 限制称为功能依赖性和连接依赖性。您需要了解规范化和其他设计原则。如果你给我们依赖关系，我们可以告诉你合理的设计。（规范化从不引入新的列名。）

您还没有解释日志信息的作用，所以我们不能多说它在您的设计中应该如何。

对于属性 x 值 x 语言 x 翻译，您需要 table（或更多取决于您使用硬连线与元数据的程度）（具有涉及它的适当完整性约束和 tables具有这些属性）。

电子商务的postgresql数据库设计

postgresql database design for ecommerce

database

postgresql

performance

database-design