在设计表时,我养成了一个习惯,即有一个唯一的列,并将其作为主键。这可以通过三种方式实现,具体取决于需求:

自动递增的标识整数列。 唯一标识符(GUID) 短字符(x)或整数(或其他相对较小的数字类型)列,可作为行标识符列

数字3将用于相当小的查找,主要是读取表,这些表可能有一个唯一的静态长度字符串代码,或一个数值,如年或其他数字。

在大多数情况下,所有其他表都有一个自动递增的整数或唯一标识符主键。

问题:-)

我最近开始使用一些数据库,这些数据库没有一致的行标识符,而且主键目前聚集在各个列之间。一些例子:

datetime /字符 datetime /整数 datetime / varchar 字符/ nvarchar / nvarchar

这有有效的理由吗?我总是为这些情况定义一个标识符或唯一标识符列。

此外,还有许多根本没有主键的表。如果有的话,合理的理由是什么?

我试图理解为什么桌子被设计成这样,对我来说,它似乎是一个很大的混乱,但也许有很好的理由。

第三个问题在某种程度上帮助我解析答案:在使用多个列组成复合主键的情况下,与代理/人工键相比,这种方法是否有特定的优势?我主要考虑的是性能、维护、管理等方面。


当前回答

从不同的字段中创建主键是没有问题的,这是一个自然键。

您可以使用Identity列(与候选字段上的唯一索引相关联)来创建代理键。

这是一个古老的讨论。在大多数情况下,我更喜欢代理键。

但是没有钥匙是没有理由的。

再保险:编辑

是的,关于这一点有很多争议:D

我没有看到任何明显的优势自然键,除了他们是自然的选择。你总是会用Name、SocialNumber或者类似的东西来思考,而不是idPerson。

代理键可以解决自然键存在的一些问题(例如传播更改)。

当你习惯了代理,它似乎更干净,更易于管理。

但最终,你会发现这只是一个品味或心态的问题。有些人用自然的钥匙能“更好地思考”,而其他人则不然。

其他回答

如果你真的想阅读关于这个古老争论的所有内容,可以在Stack Overflow上搜索“自然键”。你应该能拿到几页结果。

您应该使用由多个字段组成的“复合”或“复合”主键。

这是一个完全可以接受的解决方案,点击这里了解更多信息:)

我们做了很多连接,复合主键已经成为性能的累赘。简单的int或long即使引入第二个候选键也可以解决许多问题,但是在一个字段上连接比在三个字段上连接要容易得多,也更容易理解。

如果有天然钥匙,通常是最好的。因此,如果datetime/char唯一地标识了行,并且这两部分对行都有意义,那就太好了。

如果只有datetime是有意义的,并且只是附加了char以使其唯一,那么您不妨使用一个identify字段。

除了这些好答案,我想分享一篇我刚读过的好文章,伟大的主键辩论。

这里引用几点:

开发人员在为每个表选择主键时必须应用一些规则:

主键必须唯一地标识每条记录。 记录的主键值不能为空。 在创建记录时,主键-值必须存在。 主键必须保持稳定—您不能更改主键字段。 主键必须紧凑且包含尽可能少的属性。 主键值不能更改。

自然键(倾向于)打破规则。代理键符合规则。(你最好通读那篇文章,它值得你花时间!)