Нужны рекомендации по таблице типов для Entity Framework

Question

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

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

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

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

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

EDIT:

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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