-2 foreign-key database-design primary-key unique-constraint
我的场景是我有一个名为 PERSON 的超类型和两个子类型 EMPLOYEE 和 CUSTOMER。我在 EMPLOYEE 和 CUSTOMER 中使用来自 PERSON、PersonID 的主键作为外键。但是,我没有将它用作 EMPLOYEE 和 CUSTOMER 中的主键,而是在它们各自的表中创建了一个名为 EmployeeNum 和 CustomerNum 的新代理主键。我想知道如果我这样做会破坏某种形式良好的/规范化规则吗?例如,在 EMPLOYEE 中,我认为很清楚,personID-->(employeeid,hiredate,hourlywage) 和employeeid-->(personid,hiredate,hourlywage),本质上这两个键都可以单独标识一个唯一的行。在实践中可以吗?(也假设我不想要复合主键)。
由于 PersonID 和 EmployeeID 都是候选键(并且可能会使用唯一性约束来实现),因此您建议的表设计满足 Boyce Codd 范式,因此也满足第三范式。这并不一定使它成为一个好主意。原则上,为事物提供替代标识符并不是一件坏事,但在这种情况下,我看不到这样做的逻辑。
您似乎在说 PersonID 和 EmployeeID 都是“代理”键,但在这种情况下,您将在业务领域中使用什么自然键?我想其中至少一个实际上是员工的域密钥(“自然”密钥),但另一个是什么?应该如何使用附加密钥来增强数据完整性或可用性?
代理键意味着某些开销:额外的索引;执行数据访问和操作时的额外查找和连接;更多的代码复杂度。使用代理人的决定应慎重考虑,并考虑其优缺点。不应默认假设每个表都需要另一个代理。
归档时间: |
|
查看次数: |
230 次 |
最近记录: |