Entity framework 两个附加表是否比一个带meta的表更好？

有一个关于架构的问题：我有两个主题，DocumentLetter和DocumentOther，都应该得到经理的批准

更好的方法是：使用两个附加的模型DocumentLetterApprove和DocumentOtherApprove与实体关系，或者使用一个附加的表（不带关系，但包含有关模型标识列ModelName和ModelID的信息）

或者另一个示例，不同文档的附件

信函、合同-2个不同的表格，每个表格应有自己的附件

---

我可以为信函和合同的每个模型使用附加表，或者创建一个带有字段ModelName和ModelID？的表，如果相关实体的批准可能因其应用的不同而有所不同，我倾向于保留单独的实体/w关系。我避免使用模糊链接的表，除非它们表示可能与许多其他实体中的一个相关联的大型1对多实体

使用ParentType+ParentId之类的东西的问题在于，您无法在相关表之间利用任何形式的FK约束。这也意味着您无法利用EF关系，因为可能会多次加载其中一个文档，并希望知道该文档是否已批准，以及来自批准的详细信息

如果不同文档类型的审批预期是相同的，那么我会更快地声明一个公共审批表/实体，并在每个文档类型表上放置一个ApprovalValid，以建立从文档到审批的多对1关系

如果批准是相同的，并且可以形成多对多，则可以使用适当的多对多关系表DocumentLetter-DocumentLetterApproval FKs-批准批准详细信息

如果信函批准与其他批准可能不同，则：DocumentLetter-DocumentLetterApproval approval details

像这样的设计决策通常来自于对“请勿重复”的考虑。我能给出的建议是，KISS应该让它保持愚蠢的简单，而DRY应该只适用于被证明是相同的逻辑/结构。不仅仅是预期相同，或者更糟的是，预期相似，应该是不断改进的重新考虑因素，而不是预先设计决策。当你把自己画进角落的时候，过早地为“干”编码会耗费你的时间。通过保持代码的流动性，可以证明这些关系，如果它们被证明是相同的，则可以重新分解为单个实体。时间仍然花在重新分解上，但在必须围绕设计假设工作时，重新分解以使代码结构更好，而不是使代码更差

一个例子，在这里我可以考虑一个模糊的松散链接的链接表，就像文件附件一样。我可能有几个实体可以保存对1个或多个附件的引用。附件不是我经常需要链接的东西，而是通过一个显式的操作，我无论如何都可以对它进行额外的查询，因为我不打算在加载文档时预加载附件详细信息。在这种情况下，附件表可能有一个ParentType和ParentId索引，以便我可以快速获取特定文档或其他实体的详细信息。我永远不会尝试做像Context.Documents.Includex=>x.Attachments之类的事情，因为没有这样的参考。附件总是由单个文档访问，因此我会求助于Context.Attachments.Wherex=>x.ParentType==ParentTypes.DocumentLetter&&x.ParentId==documenLetterId.ToList

我有在系统上工作的经验，这些系统只设计了这些类型的模糊链接表。它们不仅在扩展到任何合理的规模时都非常缓慢，而且随着系统的发展和关系的性质的变化，它们也非常容易出错。记录有与预期规则不同步的趋势