数据库规范化问题

时间:2010-05-27 13:36:40

标签: database-design

我正在努力打造时尚精品店。 在这个网站上,每件产品(T恤,牛仔裤等)都属于一个系列。每个系列都有外观(T恤,牛仔裤,配饰)。产品可以属于一个集合和多个外观。我该如何设计数据库?

5 个答案:

答案 0 :(得分:1)

在“产品”表格中添加“收藏”字段。它将是您的Collection表的外键(可能只是一个ID和一个名称。)

可以看看有很多产品吗?如果是这样,请使用多对多关系(中间表)对其进行建模。

修改 您将从3个主要表开始:产品,集合,外观

然后您需要加入表:Look-Products,Collection-Looks

答案 1 :(得分:0)

我会从与这些

类似的表开始
product
----------
product_id
description

collection
----------
collection_id
name

look
----------
look_id
name

collection_look
---------------
collection_id
look_id

product_collection_look
---------------
product_id (fk1)
collection_id (fk2)
look_id (fk2)

答案 2 :(得分:0)

尝试这样的事情:

Products
ProductID    int auto increment PK
ProductName  string
CollectionID FK to Collections
...more columns if necessary...

Collections
CollectionID   int auto increment PK
CollectionName string
...more columns if necessary...

Looks
LookID        int auto increment PK
LookName      string
...more columns if necessary...

CollectionLooks
CollectionID  composite PK,FK to Collections
LookID        composite PK, Fk to Looks

ProductLooks
ProductID     composite PK, FK to Products
LookID        composite PK, Fk to Looks

答案 3 :(得分:0)

这是一个想法。我使用SQL Server语法进行说明。目前尚不完全清楚一个系列是否具有一个外观或多个外观。我假设下面看了很多,但改变它真的很容易。同样,这只是使用关系表的一个想法,但还有其他同样有效的可能性。

create table Product
(
  ProductId int not null primary key,
  Name varchar(128) not null unique
)

create table Look
(
  LookId int not null primary key,
  Name varchar(128) not null unique
)

create table Collection
(
  CollectionId not null primary key,
  Name varchar(128) not null unique
  LookId int not null references Look (LookId)
)

create table CollectionLook
(
  SurrogateId int not null primary key,
  CollectionId int not null references Collection (CollectionId),
  LookId int not null references Look (LookId),
  constraint CollectionLookConstraint unique (CollectionId, LookId)  
  -- Change the above constraint if a collection can only have one look.
)

create table ProductCollection
(
  SurrogateId int not null primary key,
  ProductId int not null references Product (ProductId),
  CollectionId int references Collection (CollectionId),
  constraint ProductConstraint unqiue (ProductId)
)

create table ProductLook
(
  SurrogateId int not null primary key,
  ProductId int not null references Product (ProductId),
  LookId int not null references Look (LookId),
  constraint ProductLookConstraint unique (ProductId, LookId)
)

答案 4 :(得分:0)

鉴于:

  • 一个集合包含产品,而产品“有”外观。
  • A Collection也有“看起来”

并且没有做出任何假设,我看到两个大问题。

集合是否可以(被分配)外观,但不包含已分配这些外观的产品?

如果为真(一个集合可以有外观但没有具有这些外观的产品),那么到目前为止所有人发布的“多个表”模型都可以使用:表格集合,产品[FK到集合],外观,集合外观,产品外观。< / p>

如果为false(一个集合不能有外观,除非其中至少有一个产品具有这些外观),那么你必须抛出CollectionLooks表,为你提供一个简单的层次结构。每当您需要确定集合的外观时,您必须从“集合到产品”到“ProductLooks”进行“查询”。如果性能在某种程度上是一个问题,你可以反规范化并设置CollectionLooks表,但保持准确将充其量是尴尬。

集合是否可以包含具有给定外观的产品,但本身不能分配该外观吗?

如果为true(集合A包含带有Look Z的产品P,但集合A本身没有Look Z),那么您必须使用多表模型,以保持看起来直观的内容。

如果为false(如果集合A包含带有Look Z的产品P,那么集合A必须具有Look Z),那么分层模型再次是最适合的。