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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

Вы можете установить это как столбец 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-й нормальной форме для многих-ко-многим (но это обеспечивает лучшую ссылочную целостность). Список ролей, разделенный запятыми, вероятно, будет таким же быстрым и менее громоздким для управления небольшим набором пользователей.

Ответ 4

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

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