4

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

Franchise
FranchiseLegalEntity
FranchiseBilling
FranchiseSignup
FranchiseAllocation
FranchiseCompliance
FranchiseMiscellaneous
FranchiseNotifications

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

然而，尝试实现这一点，并在线阅读许多页面，确认多次拆分时这是有问题的。实体框架不仅需要主实体的导航属性，还需要映射到表的所有实体之间的导航属性。对于我上面的场景，这将需要 21 个无意义的导航属性 - 如果我费心将它们设为双向，则需要 42 个。

请参阅：http ://social.msdn.microsoft.com/Forums/en-US/0f65caae-8a66-431f-aa02-4b2c68f871e9/ef-41-rc-code-first-split-one-table-into-multiple-实体？论坛=adodotnetentityframework

请参阅：如何使用 EF-Code-First 将大表分成多个离散类型

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

总结一下：

表拆分

优点：最好的查询性能，在数据库层实现最快

缺点：用废话污染我的模型和 OnModelBuilding() 方法，让其他开发人员感到困惑

跨多个表共享主键

优点：最简洁的模型和代码，非遗留数据库的推荐解决方案

缺点：实施额外的工作，可能会降低性能

我的问题：

1) EF6 是否通过 2+ 拆分改进了表拆分？

2) 有没有我没有考虑到的因素？

3）还有其他选择吗？

PS 我对使用 [ComplexType] 不感兴趣

4

2 回答 2

1

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

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

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

EF6 无法为表拆分/共享主键 + 基类构建模型？

于 2014-01-15T08:43:48.627 回答
1

有了很多假设，您可能会尝试 BCP-out 必要的字段子集，然后 BCP-in 将它们返回到所需的数据库表。这是一个简单且可重复的过程，因为 BCP-out SQL 语句在您的控制范围内，因此您始终可以只导出部分数据（例如，仅在某个日期之后创建的记录）。但同样，由于数据量巨大，它可能对您不起作用。

于 2014-01-14T07:55:35.653 回答