Тип для столбцов "Статус" в таблице sql

У меня есть (фиктивная) структура таблицы следующим образом:

ticket
  id: int(11) PK
  name: varchar(255)
  status: ?????????

Вопрос в том, какой тип данных я должен использовать для статуса? Вот мои варианты, как я их вижу:

varchar, представляющий статус - BAD, потому что нет целостности
перечисление, представляющее статус - BAD, потому что для изменения значения мне пришлось бы изменить таблицу, а затем любой код с выпадающими списками для значений и т.д. и т.д. и т.д.
int FK в таблицу состояния - ХОРОШО, потому что он динамический, ПЛОХО, потому что его сложнее осмотреть (что может быть полезно)
varchar FK в таблицу состояния - ХОРОШО, потому что он динамический и видимый при проверке. ПЛОХО, потому что ключи имеют смысл, что, как правило, неодобрительно. Интересно, что в этом случае вполне возможно, что таблица состояния имеет всего 1 столбец, что делает его прославленным перечислением

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

Update: Для варианта 4 предлагаемая структура будет статус: char (4) FK, в таблицу состояния. Итак,

ОТКРЫТО = > "Открыть"

CLOS = > "Закрыто"

"PEND" = > "Ожидание авторизации"

"PROG" = > "Выполняется

Какой недостаток в этом случае? Единственное преимущество, которое я вижу в использовании int over char, в этом случае - небольшая производительность.

Ответ 1

Перейдите с номером 3. Создайте представление, которое присоединяется к значению статуса, если вы хотите что-то проверяемое.

Ответ 2

Я бы пошел с номером 4, но я бы использовал столбец char(x). Если вы беспокоитесь о производительности, char (4) занимает столько места (и, соответственно, можно думать, о дисках, пропускной способности и времени обработки диска), как int, что также занимает 4 байта магазин. Если вы действительно обеспокоены производительностью, сделайте ее char (2) или даже char (1).

Не думайте об этом как о "значимых данных", считайте его аббревиатурой естественного ключа. Да, данные имеют смысл, но, как вы заметили, это может быть полезно при работе с данными - это означает, что вам не всегда нужно присоединяться (даже если к тривиально маленькой таблице), чтобы извлечь смысл из база данных. И, конечно же, ограничение внешнего ключа гарантирует, что данные действительны, так как они должны быть в таблице поиска. (Это можно сделать также с ограничениями CHECK, но таблицы Lookup, как правило, легче управлять и поддерживать с течением времени.)

Недостатком является то, что вы можете столкнуться с попыткой найти смысл. char (1) имеет сильную привлекательность, но если вы доберетесь до десяти или более значений, может возникнуть трудность придумать хорошие значащие ценности. Меньше проблемы с char (4), но все же возможная проблема. Еще один недостаток: если данные могут измениться, то да, ваши значимые данные ( "PEND" = "Ожидание авторизации" ) могут потерять свое значение ( "PEND" = "Переслать в домашний офис для первоначального утверждения" ). Это плохой пример; если коды, подобные этим, меняются, вам, вероятно, намного лучше переформатировать вашу систему, чтобы отразить изменения в бизнес-правилах. Думаю, моя точка зрения должна быть, если это введенное пользователем значение поиска, суррогатные ключи (целые числа) будут вашим другом, но если они внутренне определены и сохранены, вы должны обязательно учитывать более благоприятные для человека ценности. Это или вам понадобятся заметки post-em на вашем мониторе, чтобы напомнить вам, что означает значение "heck Status = 31". (У меня есть трое на моем, а липучка изнашивается каждые несколько месяцев. Расскажите о стоимости, чтобы поддерживать...)

Ответ 3

Я бы использовал INT и создавал отношение внешнего ключа к таблице состояния. INT должен определенно быть безопасным для столбца с перечисляемым статусом.

Ответ 4

Могу ли я порекомендовать вам перейти с полем statusID и иметь отдельную таблицу, сопоставляющую идентификатор с varchar?

EDIT: Я думаю, что именно то, что вы указали в пункте 3. Я думаю, что это лучший вариант.

Ответ 5

Я предполагаю, что ваша база данных имеет переднюю часть некоторого описания и что обычные пользователи не подвергаются статусу.

Итак, ваше удобство только для программистов и администраторов баз данных - важных людей, но я бы не стал оптимизировать свой дизайн для них.

Сильнее - я был бы очень осторожен в использовании "значимых" аббревиатур - самый вопиющий анализ данных, который я когда-либо видел, когда разработчик чистил некоторые данные и неправильно интерпретировал "значащий" ключ; оказывается, что "ПРОГ" не означает "запрограммировано", а "находится в процессе".

Go с опцией 3.

Ответ 6

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

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

Если вы используете сокращение как внешний ключ, тогда вы должны каждый раз думать, чтобы сделать его уникальным все время, поскольку @Philip Kelley упомянул об этом как недостаток.

Наконец, вы можете объявить тип MYISAM таблицы, если хотите.

Обновление: Отражая мнение @Philip Kelley, если слишком много статуса, тогда лучше использовать целое число как внешний ключ. Если есть только пара статусов, то может использоваться abbr как внешний ключ.

Ответ 7

Я недавно работал с множеством баз данных, которые требуют много статусов. И у меня есть несколько заметок, которые можно было бы добавить в беседу.

INT: Одна вещь, которую я обнаружил, заключается в том, что если в приложении много отслеживания, количество ссылочных таблиц может быстро стать громоздким и, как вы уже упоминали, сделать обзор базы данных нецелесообразным. (Что для некоторых моих клиентов имеет значение гораздо больше, чем минимальные миллисекунды, которые он сохранил во время обработки.)

VARCHAR: Ужасная идея для программирования, но важно учитывать, действительно ли данный статус будет использоваться кодом или просто человеческими глазами. Для последнего вы получаете неограниченный диапазон и не должны поддерживать какие-либо отношения.

CHAR (4): Использование дескриптивного столбца char действительно может быть очень хорошим подходом. Обычно я рассматриваю это только в том случае, если диапазон значений будет низким и очевидным, но только потому, что я считаю это нестандартным подходом (рискуя путаницей для новых разработчиков). Реально, вы могли бы использовать значение CHAR в качестве внешнего ключа так же, как INT, получить четкость и поддерживать паритет производительности.

Единственное, что вы не могли сделать, что я пропустил, - это математические операции (например, "<" и ">").

INT Range: гибридная стратегия, которую я опробовал, - это использовать INT, но добавляя к семантике семантику. Так, например,

1-10 being for initial stages, 
11-20 being in progress, and 
21-30 being the final stages. 
60-69 for errors, rejections

Проблема здесь в том, что если вы обнаружите, что вам нужно больше номеров, вы SOL, так как следующий диапазон уже принят. Итак, что я закончил делать (вроде), имитируя ответы HTTP:

100-199 being for initial stages, 
200-299 being in progress, and 
300-399 being the final stages. 
500-599 for errors, rejections

Я предпочитаю это простому INT, и хотя он может быть менее описательным, чем CHAR, он также может быть менее двусмысленным. Принимая во внимание, что "PROG" может означать множество вещей, хороших, плохих или доброкачественных, если я вижу, что что-то находится в диапазоне 500, я не знаю, в чем проблема, я смогу сказать вам, что есть проблема.