3

在 Sales Order Header/Detail 场景中，details 表应该具有任意主键（身份/guid）还是应该由 SalesOrderHeaderID 和 ProductID 列组成？

这是 Master/Detail 场景的一般问题，可以在包含 2 或 3 行的详细信息表中创建复合唯一键。（在上面的示例中，我们假设订单不能包含重复的产品）。

4

5 回答 5

1

如果您选择了一个自然复合键，并且您的设计稍后发生更改，以便您的订单详细信息成为另一个表（例如，货件）的主键，那么您必须将该复合键传播到新表。仅出于这个原因，我会选择任意身份作为主键。

此外，这允许您在订单中包含重复产品的未来情况

（这个问题的答案当然是普世问题，没有正确答案）

于 2012-10-08T10:56:48.330 回答
0

我会选择自然主键而不是身份/ guid 的任意主键。如果您能够使用自然键使条目唯一，那么我会走那条路。

因此，您的基本表结构将与此类似：

create table order
(
  order_id int -- PK
  order_date datetime,
  orderedby varchar(50)
);

create table products
(
  productid int, -- PK
  name varchar(50)
;

create table orderdetails
(
  order_id int,  -- PK/FK
  productId int  -- PK/FK
);
于 2012-10-08T10:52:53.460 回答
0

我会identity在表中有列和复合键。

设计看起来像：

  • SalesOrderDetailId (int, 身份)
  • SalesOrderHeaderID（整数，外键）
  • ProductID（整数，外键）
  • 其他必填字段。

两个表中仍然使用组合键，但是我发现组合表在从中选择时具有自己的标识（这对我个人而言使其不那么混乱）是一致且有用的。

于 2012-10-08T10:53:10.080 回答
0

在上面的场景中，详细信息表应该具有由 SalesOrderHeaderID 和 ProductID 列组成的主键——无论如何，您都需要在详细信息表上存储和索引 SalesOrderHeaderID，那么为什么不将它用作主键的一部分呢？

在实践中，使用 SalesOrderHeaderID 和订单行号的组合作为主键是正常的，因为通常有业务原因希望能够在同一个订单上记录同一产品的多个订单行。

于 2012-10-08T10:54:51.353 回答
0

...应该由 SalesOrderHeaderID 和 ProductID 列组成吗？

如果你给出了问题的完整描述，那么是的。

但是，您可能还没有提到其他标准，这可能会使平衡偏向于额外的“代理”键。

于 2012-10-08T16:32:47.663 回答