sql lookup id vs fixed string

Question

У меня есть статус котировки, который является либо ПРОЕКТОМ, ОТПРАВЛЕННЫМ, WON или LOST. Обычно я создавал бы таблицу поиска с идентификатором, именем, а затем связывал бы через quote_status_id, но в этом случае, когда состояния управляются системой, например. пользователи не могут создавать статусы, лучше ли использовать строку?

FYI в моем конкретном случае Я разрабатываю rest api и несколько передних концов, например. SPA и мобильное приложение, поэтому мне нужно синхронизировать состояния между бэкэнд и интерфейсом, но в зависимости от состояния есть некоторые пользовательские рабочие процессы. Вероятно, это не влияет на мой первоначальный вопрос, но мне интересно, может ли строка немного упростить мою разработку.

Answer 1

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

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

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

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

Answer 2

Строка в порядке. Идентификационная и ссылочная таблица имеют хорошее преимущество, что вы можете проверить правописание и значения, которые входят в поле. Кроме того, если статус хранится в нескольких таблицах, то эталонная таблица гарантирует, что одни и те же значения используются во всех ссылочных таблицах.

Однако, для значений в одном столе, check ограничения работает почти так же:

alter table t add constraint chk_t_status check (status in ('DRAFT', 'SENT', 'WON', 'LOST'));