Question

我正在将旧数据库系统升级到.NET + Entity Framework 6（代码优先POCO）+ PostgreSQL。为了便于编程，我希望将一个大表（200多个字段）拆分成多个实体，例如：

Franchise
FranchiseLegalEntity
FranchiseBilling
FranchiseSignup
FranchiseAllocation
FranchiseCompliance
FranchiseMiscellaneous
FranchiseNotifications

我很高兴发现EF6支持“表拆分”：将单个表映射到多个实体以将字段拆分。

然而，尝试实现此功能并在线阅读多个页面时，确认在多次拆分时存在问题。实体框架不仅需要导航属性，还需要导航属性，而不是映射到表的所有实体。对于我上面的场景，这将需要21个无意义的导航属性 - 如果我让它们双向打扰，那就需要42个。

建议使用带有共享主键的多个表，对我来说是一个选项。但是，考虑到EF臃肿的SQL查询生成，以及PostgreSQL有时随意查询优化器的复杂查询，我担心这个选项的性能（100GB +数据库）。

总结：

表格拆分

优点：最佳查询性能，在数据库层实施最快

缺点：使用垃圾污染我的模型和OnModelBuilding（）方法，让其他开发人员感到困惑

跨多个表共享主键

优点：最干净的型号＆amp;代码，非遗留数据库的推荐解决方案

缺点：实施的额外工作，可能性能较差

我的问题：

1）EF6是否改进了2+分割的表格分割？

2）我有没有考虑过任何因素？

3）还有其他选择吗？

P.S。我对使用[ComplexType]

不感兴趣

Answer 1

通过大量假设，您可以尝试将必要的字段子集和BCP中的BCP返回到所需的数据库表。这是一个简单且可重复的过程，因为BCP-out SQL语句在您的控制之下，因此您始终只能导出部分数据（例如，仅导出在特定日期之后创建的记录）。但同样，由于数据量庞大，它可能对你不起作用。

Answer 2

我已经解决的解决方案是Table Splitting选项。

这涉及为我的模型添加许多无意义的导航属性，并依赖于流畅的API。我认为这是两个邪恶中较小的一个，因为它们会产生最小的开销，并避免潜在的性能问题。

我在这个帖子中更详细地概述了解决方案（包括代码）：