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）分开，因为该网站是多种语言，因此将来我必须创建另一个表格{{1 }，product_size_color_jp ...

欢迎任何建议。

表： product_base

product_size_color_price_jp

表： product_size

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

表： product_size_color

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

表： product_size_color_price

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

表： product_size_color_price_quantity

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

更新

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

Answer 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 Tan将拥有自己的价格和数量，10 1/2 Burgandy也将如此。

我建议一个加入表的视图，并以更加可用的形式显示结果，如上所示，而不是（例如，（15,4,3,45.00,175））。视图上的触发器可以允许应用程序通过视图进行所有访问，因此应用程序仍然无法识别数据的物理布局。这些视图是一个非常强大的工具，它极大地增强了底层数据和应用程序本身的健壮性和可维护性，但却被严重缺乏利用。

Answer 2

你的“链接”很奇怪。你似乎有一些误解。您认为表存在的原因是什么？还是一个id属性？您似乎不了解关系设计的基础知识：每个基表都保存行，这些行满足关于应用程序情况的特定参数化语句，这些列的列称为谓词。查询要求满足其自己的谓词的行，该谓词是条件和基表谓词的组合。我们选择足以描述应用程序情况的基本基表谓词。请参阅this answer的“自我介绍数据库设计”部分。

您需要为每种产品，尺寸和颜色提供基本/ _base表，提供特定于特定事物的信息。当每个表的名称唯一时，您不需要需要 ID。虽然您可能想要 ID作为数据库所代表的系统中人员的唯一标识符。

接下来，您可能只需要一张包含产品，尺寸，颜色，价格和数量列的表格。不您的product_size_color_price_quantity表，其中包含更长和更长列的ID。但是你没有清楚地解释一行何时进入或停留在该表之外。即给出它的谓词。而且，考虑到其谓词以及可能出现的应用情况，您还没有准确地解释为什么后续限制适用于该表。您的示例数据未提供足够的信息。

我们是否改为拆分5向表取决于它的谓词及其限制。例如，如果价格仅取决于产品，那么您应该用product_size_color_price_quantity＆amp;替换新的product_size_color_quantity表格。 product_id_price。这种用“...... AND ...”之类的语句替换表格的想法是两个或更多，每个语句都带有“...”的语句，称为规范化。我们需要知道的用于规范化的主要表限制称为函数依赖性和连接依赖性。您需要了解规范化和其他设计原则。如果你给我们依赖，我们可以告诉你合理的设计。（规范化从不引入新的列名。）

您尚未解释日志信息的作用，因此我们无法详细说明它在您的设计中应该如何。

对于翻译，您需要一个表（或更多，具体取决于您使用硬连线与元数据的比例），用于属性x值x语言x转换（具有涉及它的适当完整性约束以及具有这些属性的表）。

用于电子商务的postgresql数据库设计

2 个答案: