SQL-таблица и перечисление C #

Предположим, у меня есть n типов пользователей в моем приложении.

Я использую перечисление UserType чтобы отличить их.

Нужно ли хранить таблицу в моей базе данных с именем UserType?

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

Это может привести к некоторому усложнению моего исходного кода.

Должен ли я признать этот компромисс?

Да, используйте как: таблицу поиска UserType, так и перечисление

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

Автоматизация перечислений
Используя T4-шаблоны, вы можете легко автоматизировать код вашего бизнес-уровня, чтобы отразить изменения БД. Поэтому всякий раз, когда вы меняете свой SQL-скрипт для изменения значений в своей таблице поиска, вы просто запускаете свои шаблоны и создаете дополнительные значения в своих перечислениях. И BTW: все шаблоны T4 могут быть выполнены одним щелчком мыши в Visual Studio 2008. Выберите свое решение в обозревателе решений и щелкните значок на мини-панели обозревателя решений. Вуаля. Все генерируемые T4.

Перечисления флагов
Они все прекрасные и денди, но это усложняет скрипты T-SQL, если вы также будете использовать их так же, как и на своем бизнес-уровне. Возможно, более разумно использовать отношения многих-многих, но вы не сможете автоматизировать создание enum, поэтому внесение изменений на уровне БД также означало бы внесение изменений на бизнес-уровень.

Часто на практике у вас есть таблица в базе данных и соответствующая нумерация в исходном коде.

Перечисление облегчает вам работу со значениями, которые в противном случае не имели бы для вас смысла.

Наличие таблицы в базе данных позволяет выполнять запросы и видеть в значениях результатов, которые имеют смысл + обеспечивать целостность данных (внешние ключи).

Задача здесь состоит в том, чтобы сохранить значения таблицы синхронизированными с значениями перечисления. Но это хорошо работает на практике.

Вы можете установить это как столбец int в базе данных, а затем использовать атрибут Flags() для вашего перечисления. Однако вы ограничены 32 UserTypes (2 ^ 32).

 [Flags] public enum UserType { None = 0, Viewer = 1, ContentEditor = 2, Editor = 4, Admin = 8, Root = 16, Disciple = 32, God = 64 } 

Обновить
Я пропустил часть, не желая читать источник. Как источник использует перечисление? Если он использует этот номер, таблица поиска не будет влиять на производительность и является хорошей идеей для справки. Если приложение использует имя строки, возможно, было бы проще принять метод поставщика ролей ASP.NET (iirc), просто используя индексированный столбец varchar для UserType в таблице пользователя.

Так:

 Name Email UserType Bob blah@blah.com admin,author 

При необходимости может быть указана справочная таблица.

Я придерживаюсь перечисляющего решения в коде, но это потому, что в большинстве проектов, которые я задействую с списком ролей, статично. Поэтому, если роли нужно настраивать, тогда лучшим вариантом будет отдельная таблица поиска, но при этом будет использоваться вышеупомянутая система флагов (вместо промежуточной таблицы «многие-ко-многим»).

Кроме того, для большого количества пользователей предпочтительнее будет Flags система Flags , и я бы предпочел бы быстрее. Вам достаточно заботиться о 3-й нормальной форме для многих-ко-многим (но это обеспечивает лучшую ссылочную целостность). Список ролей, разделенный запятыми, вероятно, будет таким же быстрым и менее громоздким для управления небольшим набором пользователей.

Я бы это сделал. Я бы создал отдельную таблицу, которая содержит все возможные типы пользователей. Поступая таким образом, вы будете следить за целостностью своих данных на уровне БД.

Почему это сделает ваш код несколько сложным? Я не понимаю это.