Отображение свойств навигации в унаследованных объектах (TPH) - PullRequest
Новая
       28

Отображение свойств навигации в унаследованных объектах (TPH)

1 голос
/ 17 октября 2011

У меня есть следующая схема базы данных:

database schema Я использую наследование Table-per-Hiearchy (TPH). Поле «Тип» таблицы «Случаи» определяет, является ли регистр регистром электронной почты или Twitter Они оба являются отношением 1: N к таблице дел.

Я использую подход базы данных с EF, и вот модель, которую я хочу использовать:

ef

Проблема в том, что я не могу отобразить свойства навигации в дочернюю таблицу, используя внешние ключи (Email.CaseId <-> Cases.Id и Tweets.CaseId <-> Cases.Id). Чего бы я хотел добиться, чтобы у сущности EmailCase было свойство навигации к электронным письмам, а у сущности TwitterCase - свойство для твитов.

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

Как я могу решить эту проблему? Должен ли я использовать Таблицу за тип (TPT) вместо TPH? Но в этом случае, например, EmailCase будет содержать только идентификатор оригинального случая, ничего более странного для меня. (Это то, что было бы сгенерировано, если бы я использовал модель вначале).

Или мне следует добавить вручную связи и свойства навигации?

1 Ответ

2 голосов
/ 18 октября 2011

Сложно ответить, потому что есть два очевидных преимущества - один голос за TPH, а другой за TPT:

  • Ваша модель идеально подходит для TPH, поскольку все свойства находятся вБазовый класс и производные классы не добавляют свойства в таблицу.Таким образом, для всех запросов для трех сущностей (или двух, если Cases является абстрактным) нужна только эта таблица, и никакие объединения не участвуют -> это хорошо для производительности.С другой стороны, база данных допускает несоответствия вашей модели, например, запись Emails с CaseId = 1 ссылается на запись Cases с этим Id = 1, но дискриминатор Type является TwitterCase.Если вы используете EF только для доступа к базе данных, этот случай не должен происходить, если EF выполняет свою работу правильно.Если у вас есть другие источники, которые могут изменить базу данных, это может произойти.

  • TPT решит проблему возможных несоответствий модели, поскольку CaseId в таблице Emails будет относиться кEmailCases таблица и CaseId в таблице Tweets до таблицы TwitterCases.Но цена в том, что у вас есть эти странные таблицы, которые содержат только один столбец для первичного ключа, и каждый запрос - независимо от того, насколько он прост - будет включать соединение между таблицей Cases и таблицами для производных типов ->плохо для производительности.

Что для вас важнее?Лично я бы немного склонялся к TPH в вашем конкретном случае - из-за выигрыша в производительности - если бы только ваше EF-приложение получало доступ к базе данных.Но я не мог окончательно решить, что делать, не зная всего контекста вашего приложения.

...