关系数据库设计 - 主键字段答案

【问题标题】：Relational Database Design - Primary Key Field关系数据库设计 - 主键字段
【发布时间】：2012-03-05 06:36:55
【问题描述】：

我有这个关系理由（存储缺席理由的文件）并具有这些属性 ID、类型和日期。问题是有很多类型的证明文件医疗，婚姻，死亡......（总共7种）每个文件都有自己的ID，代码或序列号，它们是唯一的，但大小和内容（字符，符号，数字）不同在每种类型中。我应该使用文档的ID、代码或序列号作为主键，使用ID最长的字段和VarChar（SQLServer）作为类型吗？或者我不应该，为什么？有其他选择吗？

谢谢！！

【问题讨论】：

“缺席的理由” - “被鱼搁浅”是其中之一吗？还有，死亡一号，收件人怎么填写？ “缺席的原因” - 死亡！大声笑
^^ 你完全错了，我的意思是当你身边的人去世时，你请假 3 天，理由 ID 将是死亡证明号码。

标签： sql-server database-design relational-database

【解决方案1】：

看看 ER 建模中所谓的“类别”（又名“子类型”、“子类”、“继承”）。

例如在ERwin Methods Guide中搜索“子类型关系”。

【讨论】：

【解决方案2】：

这实际上取决于您的数据库将保存多少数据。这种混合的几个字段不会那么糟糕，但是几千个，事情就会变得复杂。我建议将其分解为单独的表格，因为您知道每种表格。您有一个表，其中包含可能的 7 种类型中的每一种，以及一个包含相关理由文档的外键的理由。

example:

Justification
-------
JustificationId
DocumentId



Document (linking table)
-------
DocumentId
MedicalId
DeathId
etc.

Medical
-------
MedicalId
Date
Reason
DoctorSigning
etc.

【讨论】：

【解决方案3】：

主键的建议是：

a) 如果使用无符号整数，用于快速查找和轻松存储的整数可以达到 40 亿行

b) 应该没有业务意义，这样在业务规则变化时不受影响
所以不要使用 ID 或代码或序列号作为您的主键，因为它们会降低您的数据库速度。
但是，如果这些列具有唯一值，那么您可能需要一个唯一键约束来强制执行该约束。

【讨论】：