设计这个数据库的最佳方法Scenerio？ [英] Best way to design this database scenerio?

问题描述

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

说我们有3个实体类型公司，部门和员工。每个可以有多个附件（文件）。

哪个是最好的方法来处理？

解决方案1：

公司表

• CompanyId <
  

表表

• DeptId

员工表

• EmployeeId

AttchmentType表

• TypeId


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

附件表

• AttachmentId


• TypeId（映射到附件类型）


• entityId（映射到CompanyId / DeptId / EmployeeId） li>
  

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

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

解决方案2：

公司表

• CompanyId

表表

• DeptId

员工表

• EmployeeId

CompanyAttachments表

• AttachmentId


• CompanyId（FK）






DeptAttachments表






• AttachmentId


• DeptId （FK）






EmployeeAttachments表






• AttachmentId


• EmployeeId（FK）






优点：外键完整性





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





所以最好的方法是假设未来可能需要添加新实体？请帮助并提前感谢！





---





编辑1：





感谢您的回复家伙。





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





公司表






• CompanyId






表表






• DeptId






员工表






• EmployeeId






附件






• AttachmentId


• CompanyId（FK）


• EmployeeId（FK）


• DepartmentId（FK）






我在这里缺少一些东西？

解决方案

你的一个专业解决方案＃1不是真正的亲。如果你添加一个新的实体，那么你必须已经为这个实体添加了一个新的表，你已经在添加或者改变现有的代码去处理它了。您应该能够制作一些处理模式的通用对象，以便重复的代码不成问题。




Requirement is to store attachments for different entity types.

Say we have 3 entity types Company , Department and Employee. Each can have multiple attachments (documents).

Which is the best way to handle this?

Solution 1:

Company table

• CompanyId

Dept table

• DeptId

Employee table

• EmployeeId

AttchmentType table

• TypeId
• Types (company, dept, employee)

Attachments table

• AttachmentId
• TypeId (maps to attachment type)
• entityId (maps to CompanyId / DeptId / EmployeeId)

Pros: I can add new entity types easily in future

Cons: In this case I can't have foreign key relationship maintained between entities and attachments.

Solution 2:

Company table

• CompanyId

Dept table

• DeptId

Employee table

• EmployeeId

CompanyAttachments table

• AttachmentId
• CompanyId (FK)

DeptAttachments table

• AttachmentId
• DeptId (FK)

EmployeeAttachments table

• AttachmentId
• EmployeeId (FK)

Pros: Foreign key integrity

Cons: In order add new entity I need to have new attachment table separately.

So which is the best way to go with assuming I may need to add new entities in future? Please help and thanks in advance!

---

Edit 1:

Thanks for your reply guys.

If I want to go with solution 2, I see that creating new columns in attachments table easier instead of creating new attachment tables for every entity just to map them? something like,

Company table

• CompanyId

Dept table

• DeptId

Employee table

• EmployeeId

Attachments

• AttachmentId
• CompanyId (FK)
• EmployeeId (FK)
• DepartmentId (FK)

am I missing something here?

解决方案

I'd definitely go with solution #2. Your one pro for solution #1 isn't really a pro. If you add a new entity you're going to necessarily have to already add a new table for that entity and you'll already be adding or changing existing code to handle it. You should be able to make some generic objects that handle the pattern so that duplicated code isn't a problem.

这篇关于设计这个数据库的最佳方法Scenerio？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！