Нужен совет Entity Framework по таблице для каждого типа


Мне нужно реализовать решение с 1 базовым классом и 3 подклассами (4 класса)
Базовый класс: Пользователь< br> Подклассы: Клиент, Пользователь Office, Сотрудник

В моей базе данных есть только 3 таблицы: Пользователи, Клиенты и Сотрудники.
У меня нет таблицы OfficeUsers, так как все данные, которые мне нужны, уже есть в таблице Users.
В будущем я хочу создать отчет список клиентов, сотрудников и офисных пользователей.

Я не хочу использовать TPH, так как у меня много полей, не допускающих значения NULL, в таблице «Клиенты и сотрудники».
Должен ли я создать таблицу OfficeUsers только с UserId, чтобы реализовать TPT?
Мне кажется, это не очень хороший дизайн - у меня есть таблица только с PK, поэтому я могу правильно ее отобразить - пожалуйста, поправьте меня, если это способ сделать это.

Другой вариант состоял в том, чтобы иметь столбец UserType в таблице Users и использовать его в качестве дискриминатора, но будет ли он работать с TPT? Можно ли создать TPT с 1 отсутствующей таблицей и использовать дискриминаторы, похоже на смешение TPT и TPH, что, я думаю, невозможно.

Заранее спасибо за ваши ответы.

ИЗМЕНИТЬ:

Пожалуйста, рассмотрите также такой сценарий:
Я представляю новый класс под названием MobileUser, который также имеет те же поля, что и User. В этом случае у меня нет возможности узнать, сколько MobileUsers и сколько OfficeUsers есть в системе, не вводя новый столбец для типа пользователя.
Наличие в этом сценарии 2 пустых таблиц (только PK) лучше/хуже, чем создание зависимости в моих запросах от количества таблиц и, кроме того, предотвращение использования некоторых запросов LINQ (см. мои комментарии под ответом Ладислава Мрнки)

РЕДАКТИРОВАТЬ 2:

Есть вероятность, что в будущем мне придется добавлять поля в OfficeUser, поэтому я начинаю думать, что пустая таблица может быть каким-то вариантом, по крайней мере, код C# (запросы) будет выглядеть чище. Дайте мне знать, если у вас есть лучший подход.


inheritance entity-framework-4 table-per-type
person Lucas    schedule 25.05.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

Вы можете создать таблицу OfficeUsers, которая может содержать только PK User... только не делайте ее унаследованным типом. Теперь у вас есть список всех пользователей, которые пользуются офисом, к которым вы можете обратиться. Структура точно такая же, но мышление немного другое.

Если бы у вас было несколько офисов, у вас была бы таблица офисов с идентификатором, тогда ваш OfficeUser имел бы собственную таблицу типов, так как дополнительным полем был бы внешний ключ офиса... дающий вам различие, которое вы хотели.

Но, поскольку у вас (я полагаю) только один офис, вам не нужен внешний ключ, поэтому вам просто нужна одна таблица для хранения пользователей, которые используют офис... это "6 из одного, полдюжины из другой», на самом деле точно такой же, какой бы способ вы ни выбрали.

Вот почему я бы следовал вашему чутью во втором редактировании, вы можете добавить больше полей позже, так что вы также можете сделать «пустой» тип... потому что в любом случае вы получите таблицу, которая просто хранит ПК.

person Jonathan    schedule 15.08.2012

arrow_upward
0
arrow_downward

Если ваш OfficeUser точно такой же, как User, вам не нужен дополнительный класс. Используйте User вместо OfficeUser и производные классы для Employee и Client

person Ladislav Mrnka    schedule 25.05.2011
comment
@ladislav-mrnka Я думал об этом, но тогда я не смогу использовать такие запросы, как where user is OfficeUser или from ou in entities.Users.OfType<OfficeUser>(). Чтобы узнать количество OfficeUsers, мне нужно будет получить всех пользователей, где пользователь НЕ является клиентом или сотрудником. - person Lucas; 25.05.2011
comment
Да это правда. Вам придется использовать Where(x => !(x is Employee)) - person Ladislav Mrnka; 25.05.2011
comment
@ladislav-mrnka Да, и когда я добавлю новую таблицу, такую ​​как MobileUser, мне придется изменить запросы, чтобы убедиться, что она включает другую таблицу (в данном случае 3 не является оператором в предложении where). Как вы думаете, это решение лучше, чем создание пустой таблицы для OfficeUser? - person Lucas; 25.05.2011
comment
Нет, это не лучшее решение, но добавление пустой таблицы также не похоже на решение. Я подумаю об этом. - person Ladislav Mrnka; 25.05.2011