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

假设我们有三种实体类型：公司、部门和员工。每个可以有多个附件(文档)。

处理这个问题的最佳方法是什么？

解决方案1：

公司表

• 公司ID

部门表

• 德蒂德

员工表

• 员工ID

attchmenttype表

• 打字
• 类型(公司、部门、员工)

附件表

• 附件ID
• typeid(映射到附件类型)
• EntityID(映射到CompanyID/Deptid/EmployeeID)

优点：将来我可以轻松地添加新的实体类型

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

解决方案2：

公司表

• 公司ID

部门表

• 德蒂德

员工表

• 员工ID

公司附件表

• 附件ID
• 公司ID(FK)

拆卸附件表

• 附件ID
• DEPTID(FK)

EmployeeAttachments表

• 附件ID
• 员工ID(FK)

优点：外键完整性

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

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

编辑1：

谢谢你们的回复。

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

公司表

• 公司ID

部门表

• 德蒂德

员工表

• 员工ID

附件

• 附件ID
• 公司ID(FK)
• 员工ID(FK)
• 部门ID(FK)

我是不是错过了什么？

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

我投票赞成解决方案2，因为这样可以以适当的方式强制执行引用完整性。此外，您还可以方便地(如果需要)为特殊附件添加字段(例如，EmployeeAttachments可能具有位字段"PersonalPicture"或类似字段)

希望这是不言自明的。

。

我会选择2。

像这样：

alt文本http://img84.imageshack.us/img84/815/dbso.png

其他需要考虑的事项：

你需要把附件卷起来吗？也就是说，员工的附件与他/她的部门及其公司相关联？如果这是一个频繁的查询，那么一个单独的附件表和一个单独的、大量索引的实体查找表选项可能会提供更好的查询性能。

此外，附件是否足够多和/或足够大，以至于您需要将这些表放在单独的设备上，或者另一个存储系统(即文件系统指针)上？管理是一个问题，也是一个绩效问题。