创建子表时哪一个是好的数据库设计？

Question

在设计子表时我注意到了两种方法

方法1示例：

Master Table >>Order Table (order_id pk)
Child Table >>order_products 
table (order_id,product_id, quantity,PK (order_id,product_id))

方法2示例：

Master Table >>Order Table (order_id pk)
Child Table >>order_products table (order_product_id PK, order_id,product_id, quantity)

问题： 请注意，我们在第二种方法中使用了加法order_product_id。这是我的问题，是否使用组合主键或引入方法2中的新列？

什么是利弊。 anwer取决于关系？ （如果one-to-many方法1更好或者many-to-many方法2更好等等）

Answer 1

你似乎已经理解（或者你？）一对多和多对多关系之间的区别，所以我不确定你在问什么。

当你有一对多时，使用第二种模式;当你有多对多时，你需要第一个模式的额外表格。

Answer 2

第二个是选择，因为你在第一个中有一个复合主键：

PK (order_id,product_id)

所以你总是需要这两个值来引用记录。

我建议使用第二个，如果您需要一些限制，请在order_id和product_id上创建一个唯一索引。

Answer 3

我根本不会想到多对多。这是一个简单的一对多关系。您应该将 OrderItem标识为自己的实体，而不是链接表。

• 订单有很多OrderItems
• OrderItem有产品，数量等。
• 可能是订单和产品的唯一约束。但是有必要吗？

以这种方式看待它，显然是解决方案二：

• 订单（order_id pk）
• OrderItem（OrderItem_id PK，order_id（FK），product_id（FK），数量）

Answer 4

这不是一个设计问题 - 它与功能有关。

在你的第一个例子中 - 你如何处理订购3本书的人？进入3个不同时间的同一本书（2个孩子）？

总的来说 - 抱歉 - 细节应该包含所有的信息。这包括金额，但也包括文本和价格信息。

为什么？

因为根据您的业务情况，您可能会在订单到达后更改商品的描述或价格，这可能会更改FUTURE订单，但不会更改已处理的订单。

想象一下，我去你的商店订购了9,99的小工具，然后 - 2分钟后 - 有人将价格改为14,99。我仍然应该得到9,99的Widget，因为这是我订单输入时的价格。如果您处理我的订单14,99，那将是欺诈。

我stronyl建议变得专业。获取数据模型Ressoure Book第1卷的副本。有许多标准scnearios的数据模型 - 比如oder s处理。