I am upgrading a legacy database system into .NET + Entity Framework 6 (code-first POCO) + PostgreSQL. For ease of programming, I wish to split a large table (200+ fields) into multiple entities, eg.:

```
Franchise
FranchiseLegalEntity
FranchiseBilling
FranchiseSignup
FranchiseAllocation
FranchiseCompliance
FranchiseMiscellaneous
FranchiseNotifications

```

I was delighted to find EF6 supports "table splitting": mapping a single table to multiple entities to split the fields up.

However attempting to implement this, and reading many pages online, confirmed that this is problematic when splitting multiple times. Entity Framework requires navigation properties not just to the principal entity, but between ALL entities mapped to the table. For my scenario above, this would require 21 pointless navigation properties - 42 if I made bothered making them two-way.

See: <http://social.msdn.microsoft.com/Forums/en-US/0f65caae-8a66-431f-aa02-4b2c68f871e9/ef-41-rc-code-first-split-one-table-into-multiple-entities?forum=adodotnetentityframework>

See: [How to separate large table into multiple discrete types using EF-Code-First](https://stackoverflow.com/questions/8491619/how-to-separate-large-table-into-multiple-discrete-types-using-ef-code-first)

Using multiple tables with a shared primary key is recommended, an is an option for me. However, given EF's bloated SQL query generation, and PostgreSQL's sometimes haphazard query optimizer with complex queries, I have concerns about the performance of this option (100GB+ database).

To summarize:

**Table splitting**

*Pros*: Best query performance, quickest to implement at database layer

*Cons*: Polluting my models and OnModelBuilding() method with crap, confusing other developers

**Shared primary keys across multiple tables**

*Pros*: Cleanest models & code, recommended solution for non-legacy databases

*Cons*: Extra work to implement, potentially poorer performance

My questions:

1) Has EF6 improved the table splitting with 2+ splits?

2) Are there any factors I haven't considered?

3) Are there any other options?

P.S. I am not interested in using [ComplexType]