EF6 Разделение таблиц и общий первичный ключ для нескольких разделов

Question

Я обновляю устаревшую систему баз данных в .NET + Entity Framework 6 (с кодом POCO) + PostgreSQL. Для простоты программирования, я хотел бы разделить большую таблицу (200+) полей в нескольких объектов, например .:

Franchise 
FranchiseLegalEntity 
FranchiseBilling 
FranchiseSignup 
FranchiseAllocation 
FranchiseCompliance 
FranchiseMiscellaneous 
FranchiseNotifications 

Я был рад найти EF6 поддерживает «таблицы расщепления»: переводящий одну таблицу для нескольких объектов чтобы разбить поля вверх.

Однако, пытаясь реализовать это и прочитав много страниц в Интернете, было подтверждено, что это проблематично при расщеплении нескольких раз. Entity Framework требует свойств навигации не только для основного объекта, но и для всех объектов, сопоставленных с таблицей. Для моего сценария выше это потребует 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-entities?forum=adodotnetentityframework

См: How to separate large table into multiple discrete types using EF-Code-First

Использование нескольких таблиц с общим первичным ключом рекомендуется, вариант для меня. Однако, учитывая раздутое генерирование SQL-запросов EF и иногда беспорядочный оптимизатор запросов PostgreSQL со сложными запросами, у меня есть проблемы с производительностью этого параметра (100GB + database).

Резюмируя:

Таблица расщепления

Pros: Лучшая производительность запросов, быстрый для реализации на уровне базы данных

Cons: Загрязняющие мои модели и метод OnModelBuilding() с дерьмо, запутывание других разработчиков

Общие первичные ключи по нескольким таблицам

Pros: Чистейшие модели & код, рекомендуемое решение для не устаревших баз данных

Против: Дополнительная работа по реализации, потенциально худшие характеристики

Мои вопросы :

1) У EF6 улучшилось расщепление таблицы с расщеплением 2+?

2) Есть ли какие-либо факторы, которые я не учитывал?

3) Есть ли другие варианты?

P.S. Я не заинтересован в использовании [ComplexType]

Answer 1

Решение, на котором я остановился, является опцией Table Splitting.

Это связано с добавлением большого количества бессмысленных свойств навигации для моих моделей и использования свободного API. Я думаю, что это меньшее из двух зол, поскольку они вызывают минимальные накладные расходы и избегают потенциальных проблем с производительностью.

я изложил решение более подробно (включая код), в этой теме:

EF6 failing to build model for Table Split/Shared Primary Key + Base class?

Answer 2

С большим количеством предположений вы можете попытаться выполнить BCP-выход необходимых подмножеств полей и BCP-в них обратно в нужные таблицы DB. Это простой и повторяемый процесс, поскольку SQL-оператор BCP-out находится под вашим контролем, поэтому вы всегда можете экспортировать только часть данных (скажем, только записи, созданные после определенной даты). Но опять же, это может не сработать для вас из-за большого количества данных.