【问题标题】：Should I create a table with multiple candidate keys?我应该创建一个包含多个候选键的表吗？
【发布时间】：2014-06-13 12:56:15
【问题描述】：
假设我有一张桌子：
MyTable(AttrA, AttrB, AttrC)
Functional dependencies: (AttrA, AttrB) -> AttrC, (AttrA, AttrC) -> AttrB
我选择(AttrA, AttrB) 作为主键。那么这个设计是好是坏呢？
【问题讨论】：
标签：
database
database-design
primary-key
functional-dependencies
【解决方案1】：
如果业务情况是这样的，而且这个解决方案准确地反映了业务场景，那么它可能有什么“不好”的地方？
编辑
我假设您知道这样的设计可能会让您遇到某些“交换”更新的问题，但也许最好明确说明这一点。这种“交换”更新最简单的情况是当您需要从 {A,B,C} {A,C,D} 更改为 {A,B,D} {A,C,C} 时。有哪些方法可以克服这些问题取决于您的 DBMS。当然，某些更新在实践中可能难以实现这一事实并不会导致数据库的逻辑结构本身无效。
很抱歉才迟到才提到这一点。