我们如何决定使用身份列或主键？
问问题
7846 次
4 回答
4
这两个概念并不相互排斥。所有组合都是可能的：
- 一个身份列，它也是一个主键，
- 不是主键的标识列，
- 不是身份的主键列，
- 既不是主键也不是标识的列
请注意，标识列通常用作主键，因为它保证是唯一的，并且通常是必需的架构字段的补充，因此如果架构更改，它不会更改。
于 2012-10-17T10:28:05.780 回答
2
当您需要自动增量时，您可以使用标识列。时期！就那么简单。通常，标识列是主键的良好候选者。
主键只是一个概念。主键背后的重要之处在于它在列上创建了一个 CLUSTERED INDEX，因此理论上，如果您有一个具有唯一聚集索引的表，则不需要“主键”。
我建议你谷歌并阅读这两个概念，这对理解非常重要
于 2012-10-17T10:30:43.937 回答
1
从经验而不是理论来看，我发现使用用户不共享的密钥作为“用户数据”很重要。也就是说，用户数据和键应该是不同的字段。
我们有一个使用项目代码的数据库。项目代码是唯一的，永远不会为空，并且具有一旦分配就永远不会更改的业务规则。这使它成为候选键。
但是，如果用户看到项目代码，按项目代码查找文件等等，这是他们的数据，他们会想围绕项目代码更改业务规则。
我们的项目代码是客户 ID，后跟一个破折号和一个序列号，以使其唯一。如果针对一个客户 ID 的提议项目最终与不同客户 ID 签订了合同，则用户希望更改项目代码。如果用户输入了错误的客户 ID，他们想更改项目代码。更改主键以及引用它的所有外键都是有问题的。
这并没有（似乎）回答这个问题我们如何决定使用身份列或主键？
但是，如果您不将客户数据用作主键（正如我刚才所说，您不应该使用），那么主键将需要自动生成，因为您不能期望用户输入它。
于 2012-10-17T10:51:44.387 回答
0
您应该始终使用主键，它只会使您的数据库具有可扩展性。使用 GUID 或 UUID 或其他任何唯一的东西。
于 2012-10-17T10:28:50.543 回答