设计此数据库方案的最佳方法是什么？答案

【问题标题】：Best way to design this database scenario?设计此数据库方案的最佳方法是什么？
【发布时间】：2011-03-25 09:22:38
【问题描述】：

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

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

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

解决方案 1：

公司表

公司编号

部门表

部门编号

员工表

员工编号

附件类型表

类型标识
类型（公司、部门、员工）

附件表

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

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

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

解决方案 2：

公司表

公司编号

部门表

部门编号

员工表

员工编号

公司附件表

附件 ID
公司 ID (FK)

部门附件表

附件 ID
部门 ID (FK)

EmployeeAttachments 表

附件 ID
EmployeeId (FK)

优点：外键完整性

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

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

编辑 1：

谢谢你们的回复。

如果我想使用解决方案 2，我发现在附件表中创建新列比为每个实体创建新附件表来映射它们更容易？比如，

公司表

公司编号

部门表

部门编号

员工表

员工编号

附件

附件 ID
公司 ID (FK)
EmployeeId (FK)
部门 ID (FK)

我错过了什么吗？

【问题讨论】：

您看过基于文档的 NoSQL（即 CouchDB）数据库吗？

标签： sql-server database-design

【解决方案1】：

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

【讨论】：

通过 FK 强制执行的数据完整性每次都比维护时间更短（尤其是一种可能永远不需要的维护）！
+1，解决方案 #1 可能有问题，当您在 CompanyId / DeptId / EmployeeId 中具有相同的键值时会发生什么情况，例如您使用身份/自动增量值。

【解决方案2】：

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

【讨论】：

+1，add fields for special attachments 用户最终会想要这个。

【解决方案3】：

希望这是不言自明的。

【讨论】：

谢谢达米尔。如果我们从头开始，我希望这一定是最佳解决方案。但不幸的是，就我而言，这些实体已经在使用中，并且有自己的 ID。

【解决方案4】：

我会选择选项 2。

类似这样的：

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

【讨论】：

我喜欢这个解决方案，因为附件表对于所有实体都将具有相同的属性。
@puzzled 不常见的字段将转到其专用表

【解决方案5】：

其他需要考虑的事项：

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

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

【讨论】：

不。附件只是与其对应的实体相关，不会卷起。附件表只存储文件路径/url。实际文件存储在文件服务器上。
好吧，单独的表是要走的路。我确实认为您应该拥有所有文件名或路径的联合视图，以便您可以审核数据。即是否有人不小心删除了文件等...此外，如果需要存档，请考虑如何处理压缩内容并移动到不同的设备（即从一个磁盘到另一个磁盘到 DVD 等）。