使用设计器定义的ID与自动生成的ID相比较

Question

这更多的是实际数据库设计的问题。我之前设计了较小的数据库，但是现在我所做的（数百万条记录）级别上没有任何数据库，现在我需要比以前更多地考虑效率和性能。

请考虑以下事项：正在给予一个ID为10位左右的大表。这当然是主要关键。根据我的理解，将密钥存储为整数是不好的做法，除非您计划对其进行数学计算（如果我在这里错误，请纠正我）。最好的做法是将密钥存储为nvarchar（n），其中n是密钥的字符串长度？做自己的主键（比如增量键）怎么样？密钥的大小会更小，但是否足以影响您可以直接将数据导入已定义关系的数据库的事实？ （使用另一个表中的外键导入表，如状态码一样）。

Answer 1

除非需要前导零，否则将密钥存储为整数是一种很好的做法。您希望密钥的大小尽可能加快连接速度。

大多数数据库都有一种自动设置增量密钥的方法，如果你需要的话，这往往是最好的方法，除非你无法承担由于回滚而在序列中丢失任何数字。实际上只有少数几种类型的事物可能会有一个leagl或regulartory要求，因此您不能跳过序列中的项目，所以如果您想使用代理键，自动生成的id是最佳选择之一。除非需要，否则不要自己创建增量密钥，因为您不会像数据库执行自动化密钥那样有效地完成此操作，并且如果发生错误，您可能会遇到竞争状况，并且子表可能最终分配给错误家长ID。

如果您有保证的唯一值（即不变），则可以使用自然键代替代理。它可能会减慢连接速度，但也可能意味着您不必进行多次连接。但是，如果您使用自然键，请确保它实际上是唯一的，并且它只会很少发生变化。诸如人名，公司名称，电子邮件地址等不是一个好主意，汽车的VIN号码是好的。请记住，由于公司名称已更改，因此您不想更改一千万条子记录。