一个大表或单独的表来存储零件类型的产品评论？

Question

我需要制作100个左右的表格。我有一个名为PartStatsXXX的表，要制作的表都将被称为PartReviewXXX（它们以1：n的关系相互配对）。

创建一个大表来存储所有产品（从业务角度来看产品和部件是同一个术语）评论是否有效？有人提到从PartStatsXXX到PartsReview（一个大表）建立一个关系，其值为XXX，作为PartStatsXXX主键的一部分。

XXX是零件类型的名称（例如电池，接线织机等）。所以这将是varchar。我应该制作复合钥匙吗？零件类型不会更改名称（尽管某些零件名称可能有多个名称，具体取决于文化），但它实际上不是候选ID。然后提到我可以根据XXX的值获得我需要的几个视图。

我希望这是有道理的。什么是最好的方法？

由于

Answer 1

多表PartStatsXXX是一个坏主意：难以正确编码或使用框架，难以维护，难以查询......

使用两个表：PartStats和PartsReview，使用适当的密钥和性能索引。

Answer 2

根据您要在每个表中存储的内容创建表更有效。 100个产品不需要100个表。所有产品都需要1张桌子。

因此，根据您的需要，我会创建2个表：

products
========
id INT
name VARCHAR 

product_reviews
===============
id INT
product_id INT (foreign key to products.id)
rating INT (example column)

Answer 3

除非您为每个产品的评论存储不同类型的数据（即每个表具有不同的列集），否则每个产品使用不同的表格将会产生不必要的噩梦。

作为一般规则，您永远不希望拥有多个具有相同列集的表。正如已经建议的那样，一个带有“product_id”列的表是可行的方法。

Answer 4

如果你想以快速和肮脏的方式省去一些痛苦，请使用两张桌子。

CREATE TABLE PartStats (
  ...,
  PartType VARCHAR(255),
  ...
);

CreateTable PartReview (
  ...
  PartType VARCHAR(255),
  ...
);

然后通过

加入他们

SELECT ...
FROM PartStats ps JOIN PartReview pr
  ON ps.PartType = pr.PartType;

这可以帮助您摆脱数百个表，但可以解决另一个问题：可能不同步的冗余数据（PartType）。 PartType中的拼写错误可以产生孤立的评论。

此处的解决方案（假设您可以为给定的PartType提供多个PartStats条目）是将第三个​​表添加到唯一较旧的PartType名称。

CREATE TABLE PartType (
  ID INT ...,
  PartType VARCHAR(255),
  PRIMARY KEY (ID)
);

并安排PartStats和PartReview使用PartType的ID。例如，

CREATE TABLE PartStats (
  ...,
  PartType_ID INT REFERENCES PartType(ID),
  ...
);

CREATE TABLE PartReviews (
  ...
  PartType_ID INT REFERENCES PartType(ID),
  ...
);

这将阻止您为不存在的PartType制作PartStats或PartReview。

如果查询性能成为问题，则在PartType_ID上添加辅助索引将有所帮助。

Answer 5

我可以推荐一些关于数据库设计的不错的书（几个月前我决定提高我的数据库设计技能，所以我看了几本不同的书并选择了这两本书）：

1） Pro SQL Server 2008关系数据库设计与实现（c）Louis Davidson
2）关系数据库设计清楚地解释了（c）Jan Harrington

祝你好运！