Предоставляет ли перечисление в коде более надежную модель предметной области, чем статическая таблица?

Question

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

В качестве примера предположим, что у меня есть объект Marble с атрибутом Color.Атрибут цвета имеет конечный набор возможных значений, скажем, красный, зеленый, синий.Скажем, команда базы данных рекомендует иметь статическую таблицу S_ValidColors для достижения следующих целей:

-----------------------
| ColorId | ColorName |
-----------------------
|    0    |    Red    |
-----------------------
|    1    |   Green   |
-----------------------
|    2    |    Blue   |
-----------------------

Принимая во внимание, что я больше думаю о строках (это всего лишь набросок общей концепции):

public class Color {
    public static const Color Red = Color(0);
    public static const Color Green = Color(1);
    public static const Color Blue = Color(2);

    private Color(uint typeCode) {
        ...
    }
    ...
}

Помимо вопроса о том, что лучше (который, вероятно, зависит от множества других факторов, не представленных здесь), затрагивает ли этот вопрос, насколько сильна модель предметной области?Один способ больше анемия, чем другой?

Answer 1

Это полностью зависит от использования перечисления.Если они будут часто меняться, то лучше в БД, вы не хотите перекомпилировать и переустанавливать раз в неделю, потому что Джо снова сменил свой любимый цвет.Если перечисление более фиксировано, чем жесткое кодирование, оно будет лучше, о нем легче рассуждать и с меньшей вероятностью сломается.Вам нужен доступ к нему из хранимых процедур?Может быть хорошей идеей иметь его в базе данных, где к нему могут получить доступ как хранимые процедуры, так и обычный код.Вам действительно не нужна головная боль, связанная с поддержкой двух разных версий одного и того же.Как выглядит логика, использующая это перечисление?Бывают ситуации, когда любой вариант более практичен.

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

Answer 2

У нас была точно такая же дискуссия несколько лет назад на моей старой работе.В итоге выбираем 2-й вариант.Рассуждение таково:

Когда вы что-то меняете в БД, вы ожидаете, что эти изменения будут работать без необходимости повторного развертывания приложения.Но в случае такого рода перечислений код может зависеть от того, что для этого перечисления есть точные значения.Допустим, у вас есть переключатель, который использует это перечисление, и если указано недопустимое значение, он выдает исключение.Жестко запрограммировав значения, вы можете гарантировать, что ваш код не вызовет ошибок в этих перечислениях.Даже когда какой-нибудь "умный" администратор решит добавить свои значения.

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

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

Answer 3

Создание статической модели базы данных может доставить некоторые трудности без каких-либо преимуществ:

• Чтение из базы данных будет медленнее;
• Если значения цвета изменятся, развертывание обновления будет более сложным, поскольку вам нужно будет обновить не только источник, но и базу данных;
• Как упоминалось в Euphoric, вы будете более подвержены ошибкам, если некоторые объекты в БД отсутствуют или изменены.

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