在什么情况下我们需要在数据库中使用复合键
我已经看到我们可以拥有复合键,其中主键由两个表的组合主键组成。
喜欢的人和书
person_id and book_id will make the primary key.
但我想问的是,我们需要对编程语言进行硬编码
我的意思是可以,我可以有任意名称的单独列作为主键,然后我不必对其进行硬编码,并且可以像平常一样执行我的功能
id,person_id ,book_id
-
在“新”应用程序中不应考虑使用组合键。过去,曾经有人认为“业务密钥”比“代理密钥”更好。
编辑:按照克里斯的要求,我正在扩大答案。
首先,我要说明我将这个问题理解为“复合主键”与“代理键”。
另外,我也承认在 一个
用例中复合键很有意义:在交叉引用表(也称为“链接表”)中。这些用于多对多表,仅包含两个字段,两个外键均构成外部参照表的主键。例如,UserRole
表将包含user_id
和role_id
,仅此而已。例如,对于Java这样的表,没有类表示形式。通常是a
@ManyToMany
,Collection
两边都有a 。我在另一个答案(Hibernate:CompositePKvsSurrogatePK中的观点)中分享了我对Natural键与Surrogate键的看法,并且我相信Composite键在没有带来任何实际好处的情况下也具有Natural键的一些缺点。
复合键的问题在于,您将需要_两个_值来唯一地标识一条记录。一旦开始拥有引用该第一个表中的记录的表,这将成为一个问题。然后,第二个表需要 两
列才能引用 一条 记录。并且,如果第二个表使用由单个值+外键组成的复合键,则您现在具有 三 列来唯一地标识 一条 记录。第三张表将需要这 三_列额外的列,以仅引用第二张表中的 _一条 记录。真的,这是雪球。另一个缺点是需求 确实会 发生变化。每时每刻。因此,今天看来是好的组合键并不是明天的所有键。这就是我们拥有替代钥匙的原因:要面向未来。
复合键主要用于使表中的记录基于一组列而唯一。例如,如果您有一个
Customers
表,则可能有一个NationalId
+Country
作为唯一值,这意味着如果两个用户所在的国家/地区是美国,则两个用户不能共享相同的SSN。但是,如果两个记录不在同一国家/地区,则它们的编号可能相同。如果您喜欢组合键,那么这将是一个不错的选择。但是正如我之前所暗示的,您可以使用代理键并应用unique
约束。您将拥有复合钥匙的优势以及代理钥匙的安全性。