设计此数据库方案的最佳方法？

Question

要求是存储不同实体类型的附件。

假设我们有3个实体类型Company，Department和Employee。每个都可以有多个附件（文档）。

哪种方法可以解决这个问题？

解决方案1：

公司表

• CompanyId

部门表

• DEPTID

员工表

• EMPLOYEEID

AttchmentType表

• TYPEID
• 类型（公司，部门，员工）

附件表

• 附件ID
• TypeId（映射到附件类型）
• entityId（映射到CompanyId / DeptId / EmployeeId）

优点：我可以在以后轻松添加新的实体类型

缺点：在这种情况下，我不能在实体和附件之间保持外键关系。

解决方案2：

公司表

• CompanyId

部门表

• DEPTID

员工表

• EMPLOYEEID

CompanyAttachments表

• 附件ID
• CompanyId（FK）

DeptAttachments表

• 附件ID
• DeptId（FK）

EmployeeAttachments表

• 附件ID
• EmployeeId（FK）

优点：外键完整性

缺点：为了添加新实体，我需要单独添加新的附件表。

那么假设我将来可能需要添加新实体，这是最好的方法吗？

---

修改1：

感谢您的回复。

如果我想使用解决方案2，我会看到在附件表中创建新列更容易，而不是为每个实体创建新的附件表来映射它们？ 像，

公司表

• CompanyId

部门表

• DEPTID

员工表

• EMPLOYEEID

附件

• 附件ID
• CompanyId（FK）
• EmployeeId（FK）
• DepartmentId（FK）

我在这里错过了什么吗？

Answer 1

我肯定会选择解决方案＃2。你解决方案＃1的专业人士并不是专业人士。如果添加新实体，则必须已经为该实体添加新表，并且您已经在添加或更改现有代码以处理它。您应该能够创建一些处理模式的通用对象，以便重复的代码不是问题。

Answer 2

我投票支持解决方案2，因为这样您就可以以适当的方式强制执行参照完整性。此外，您可以轻松地（如果需要）为特殊附件添加字段（例如，EmployeeAttachments可能有一个字段“PersonalPicture”或类似字段）

Answer 3

我会选择2。

这样的事情：

alt text http://img84.imageshack.us/img84/815/dbso.png

Answer 4

希望这是不言自明的。

Answer 5

需要考虑的其他事项：

您是否需要汇总附件？即员工的附件是否与他/她的部门及其公司相关联？如果这是一个频繁的查询，单个附件表和一个单独的重度索引实体查找表选项可能会提供更好的查询性能。

此外，附件是否足够多和/或足够大，您需要将这些表放在单独的设备或其他存储系统（即文件系统指针）上？管理既是一个问题，也是一个表现。