database-design - 支持表上的自然键与代理键

<分区>

我读过很多关于自然主键与代理主键之间的较量的文章。我同意使用代理键来识别其内容由用户创建的表的记录。

但是在支持表格的情况下我应该使用什么？

例如，在一个假设的表“orderStates”中。此表中的值不可编辑(用户不能插入、修改或删除此值)。

如果您使用自然键，将有以下数据:

TABLE ORDERSTATES
{ID: "NEW", NAME: "New"}
{ID: "MANAGEMENT" NAME: "Management"}
{ID: "SHIPPED" NAME: "Shipped"}

如果我使用代理键将有以下数据:

TABLE ORDERSTATES
{ID: 1 CODE: "NEW", NAME: "New"}
{ID: 2 CODE: "MANAGEMENT" NAME: "Management"}
{ID: 3 CODE: "SHIPPED" NAME: "Shipped"}

现在让我们举个例子:用户输入了一个新订单。

在使用自然键的情况下，在代码中我可以这样写:

newOrder.StateOrderId = "NEW";

每次我有一个额外的步骤时，都使用代理键。

stateOrderId_NEW = .... I retrieve the id corresponding to the recod code "NEW"

newOrder.StateOrderId = stateOrderId_NEW;

每次我必须将订单移动到新状态时，都会发生同样的情况。

那么，在这种情况下，选择一种 key 类型而不选择另一种 key 类型的原因是什么？

最佳答案

答案是:视情况而定。

在您更改代码中的订单状态的示例中，问问自己，您为这些状态创建常量的可能性有多大(例如，避免拼写错误)。如果是这样，两者将完成相同的任务。

在通过表单提交新订单状态的情况下，您可以使用自然键或代理键构建(例如)可能值的下拉列表，这没有区别。

当您在订单表上执行查询并希望打印每个订单的状态时，情况会有所不同。拥有一个自然键将避免进行另一个连接的需要，这有帮助(尽管有点)。

在存储和查询性能方面，代理键在大多数情况下分别更小和更快(取决于表大小)。

不过话虽如此，还是需要慎重考虑。我个人觉得代理键已经成为一种教条。许多开发人员会在他们的所有表格中使用它们，建模软件会在创建表格时自动添加它们。因此，您可能会对您的选择产生不同的 react ，但没有硬性规定禁止您使用它们；明智地选择:)

关于database-design - 支持表上的自然键与代理键，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12748473/

相关文章：

session 消息系统的SQL表设计