Предположим, что у меня есть n типов пользователей в моем приложении.
Я использую перечисление UserType, чтобы отличить их.
Нужно ли хранить таблицу в моей базе данных с именем UserType?
Так что я могу найти тип пользователя в любое время, запросив таблицы, а не искать исходный код приложения.
В результате мой исходный код может стать несколько сложным.
Должен ли я признать этот компромисс?
Для понимания структур данных мы создаем таблицы поиска с определенными типами, хотя они никогда не меняются. Таким образом, вы сохраняете ссылочную целостность, также связывая таблицы с этим поиском.
Автоматизировать перечисления
Используя с использованием шаблонов T4, вы можете легко автоматизировать свой код бизнес-уровня, чтобы отразить изменения БД. Поэтому всякий раз, когда вы меняете свой SQL script для изменения значений в своей таблице поиска, вы просто запускаете свои шаблоны и создаете дополнительные значения в своих перечислениях. И 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 [email protected] admin,author
При необходимости может быть таблица ссылок.
Я придерживаюсь перечисляющего решения в коде, но это потому, что в большинстве проектов, связанных с списком ролей, статично. Поэтому, если роли нужно настраивать, то лучшим вариантом будет отдельная справочная таблица, но при этом будет использоваться вышеупомянутая система флагов (вместо промежуточной таблицы "многие-ко-многим" ).
Кроме того, для большого количества пользователей предпочтительной будет де-нормализованная система Flags, и я бы предпочел бы быстрее. Вам достаточно заботиться о 3-й нормальной форме для многих-ко-многим (но это обеспечивает лучшую ссылочную целостность). Список ролей, разделенный запятыми, вероятно, будет таким же быстрым и менее громоздким для управления небольшим набором пользователей.
Я бы сделал это. Я бы создал отдельную таблицу, которая содержит все возможные типы пользователей. Поступая таким образом, вы будете следить за целостностью своих данных на уровне БД.
Почему это сделает ваш код несколько сложным? Я этого не понимаю.