Стоит ли создавать отдельные таблицы для фиксированных опций?

Question

Как показано ниже, в нескольких местах в моем дизайне БД я создаю таблицы для «опций», если хотите. Пример, этапы запроса предложений. Которые будут содержать такие вещи, как «Завершить», «Торги» и т. Д.

Я делаю это, потому что это было рекомендовано мне в один момент в вопросе, который был удален. Это правильный способ сделать это? Или я должен просто сохранить эти параметры в виде текста, учитывая, что существует только 5 или около того возможностей?

Answer 1

Дополнительные поля

Если ваш список возможных значений, таких как rfp_stage, включает в себя больше, чем просто имя, тогда вы определенно хотите, чтобы в ваш дизайн была добавлена ​​таблица соответствия. Например, чтобы отследить цвет, используемый для «Complete», и другой цвет для «Bidding», вам нужно второе поле color вместе с name в справочной таблице rfp_stage.

Одно поле

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

Вы можете применить список возможных значений в вашем приложении (ах).

В качестве резервной копии для принудительного применения приложения, если вы используете мощную систему баз данных, такую ​​как Postgres , вы можете определить домен возможных значений и требовать, чтобы поле всегда имело значение в этой области. Попытка добавить или обновить строку с неожиданным значением завершится неудачно с ошибкой, выданной механизмом базы данных.

Обработка изменений до значения

Опять же, если есть какая-либо возможность изменения названий любого этапа, таких как «Ставка» на «Вне заявки» (то же значение, другая формулировка), тогда справочная таблица полезна как отдельная место для обновления формулировки. Нет необходимости выполнять массовое обновление значений во многих строках.

Интернационализация

Точно так же, если вам нужно локализовать отображение каждого этапа запроса предложений, скажем, чтобы показать «Завершено» и «Ставки» на французском или японском языке, то вам необходимо добавить справочную таблицу. Вероятно, у вас будет еще одна справочная таблица для хранения строк локализации, но это выходит за рамки этого ответа. Поиск переполнения стека и, возможно, DBA Stack Exchange для получения дополнительной информации.

Enum

Наконец, некоторые люди могут использовать перечисление в базе данных в качестве резервного значения для представления каждого возможного значения. Например, «1» для «Завершено», «2» для «Торги» и т. Д. Обычно я сам избегаю такого подхода, поскольку он делает чтение данных из строк неудобным и неудобным.

Контекст

Как и во многих дизайнерских решениях, четкого золотого правила не существует. Контекст имеет значение.