Сохранение значений enum в базе данных

FYI: Я явно подразумеваю SQL Server 2000-8 и С#. Поэтому СУБД с поддержкой перечислений, такими как MySql, не является предметом моего вопроса.

Я знаю, что этот вопрос задавался несколько раз в SO. Но все же, я вижу в ответах, что используются разные подходы к хранению значений enum в db.

Сохранить enum как int в db и извлечь значение enum (или атрибут описания перечисления с помощью отражения) в коде:
это подход, который я обычно использую. Проблема в том, что когда я пытаюсь выполнить запрос из базы данных в SSMS, извлеченные данные трудно понять.
Сохранить enum как строку (varchar) в db и вернуть обратно в int в коде.
На самом деле это может быть лучшим решением. Но (не смейтесь!) Это не так. Я не уверен в минусах. (За исключением большего пространства в db, которое обычно приемлемо). Что-нибудь еще против этого подхода?
У вас есть отдельная таблица в db, которая синхронизируется с определением перечисления кода и создает отношение внешнего ключа между вашей основной таблицей и таблицей перечисления.
Проблема в том, что позже нужно добавить другое значение enum, и код, и db должны обновляться. Кроме того, могут быть опечатки, которые могут быть больно!

Итак, в общем случае, когда мы можем принять накладные расходы на db во втором решении, что было бы лучшим способом для хранения значений enum в db? Есть ли общее правило шаблона шаблона об этом?
Спасибо.

Ответ 1

Нет определенного правила построения (что я знаю), но я предпочитаю подход № 1.

Я предпочитаю этот подход. Это просто, и перечисления обычно компактны, и я начинаю вспоминать, что означают цифры.
Это более читаемо, но может помешать рефакторингу или переименовать ваши значения перечисления, когда захотите. Вы теряете свободу своего кода. Внезапно вам нужно вовлечь DBA (в зависимости от того, где/как вы работаете), чтобы изменить значение перечисления или страдать вместе с ним. Анализ партитуры имеет некоторое влияние на производительность, так как такие вещи, как Locale, вступают в игру, но, вероятно, незначительны.
В чем проблема? У вас все еще есть нечитаемые числа в таблице, если вы не хотите добавлять накладные расходы на соединение. Но иногда это правильный ответ тоже в зависимости от того, как используются данные.

ИЗМЕНИТЬ: У Криса в комментариях была хорошая точка: если вы идете вниз по цифровому подходу, вы должны явно назначать значения, чтобы их также можно было переупорядочить. Например:

public enum Foo
{
     Bar = 1,
     Baz = 2,
     Cat = 9,
     //Etc...
}

Ответ 2

Одна из идей, которую я видел до того, как вы больше 3-го варианта

Таблица в базе данных (для внешних ключей и т.д.)
Соответствующий Enum в клиентском коде
Проверка запуска (через вызов базы данных) для обеспечения соответствия

Таблица таблиц базы данных может иметь триггер или ограничение проверки, чтобы уменьшить риск изменений. Он не должен иметь никаких разрешений на запись, поскольку данные привязаны к выпуску кода клиента, но он добавляет коэффициент безопасности, если DBA bollixes up

Если у вас есть другие клиенты, читающие код (что очень часто), база данных имеет полные данные.