enum vs typeId в спящем режиме - PullRequest
0 голосов
/ 09 июля 2011

Я реализую таблицу базы данных следующим образом:

Do_Something
------------
Id
Name
Frequency

Частота может быть только 1 из 3 значений на данный момент ;немедленное, ежедневное или еженедельное.Таким образом, я могу реализовать поле Frequency как String, и в этом случае отображение гибернации будет простым и легким enum.Однако, как бы ни была проста реализация кода, она кажется уродливой и неэффективной на стороне базы данных с сотнями тысяч String с.Поэтому, возможно, у меня была таблица частот:

Frequency
---------
Id
Value

А теперь у меня есть поле Do_Something.Frequency в качестве внешнего ключа к этой таблице.Теперь мне нужно жестко закодировать предустановленные частоты в моем коде, чтобы упростить обработку запросов к таблице Do_Something.Я не уверен, насколько часто будет использоваться таблица частот помимо таблицы Do_Something.Возможно, в будущем другие таблицы будут использовать его ...

Так что вопрос в том, могу ли я сделать частоту простым enum в коде и в БД как String, или сделать частотуenum в коде, который преобразуется в и излучает частоту в дБ или создает частотные константы в коде, которые соответствуют различным возможным частотным идентификаторам в дБ?

1 Ответ

0 голосов
/ 09 июля 2011

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

Я бы рассмотрел enum с некоторыми дополнительными отображаемыми именами и хорошо установленными именами строк. Это даст вам возможность переименовать название презентации, если это необходимо, без изменения базы данных. Например:

IMMEDIATE("Immediate"),
DAILY("Daily"),
WEEKLY("Weekly")

Недостатком является то, что если вы когда-нибудь решите изменить эти значения перечисления, вам придется перенести базу данных. Но с практической точки зрения, зачем вам их переименовывать?

...