MySQL ENUM type vs join tables


мое требование

таблица должна поддерживать статус.

этот столбец представляет одно из 5 состояний.


начальный конструкция

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

  • 0 = start
  • 1 = под управлением
  • 2 = разбился
  • 3 = пауза
  • 4 = остановились

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

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

5   51   2008-12-12 09:34:36

5 ответов:

  • изменение набора значений в перечислении требует ALTER TABLE Что может привести к реструктуризации таблицы -- невероятно дорогостоящая операция (реструктуризация таблицы не происходит, если вы просто добавляете одно новое значение в конец определения перечисления, но если вы удалите его или измените порядок, он выполняет реструктуризацию таблицы). В то время как изменение набора значений в таблице подстановки так же просто, как вставка или удаление.

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

  • очень сложно запросить перечисление, чтобы получить список различных значений, в основном требуя, чтобы вы запросили определение типа данных из INFORMATION_SCHEMA, и разбор списка из большого двоичного объекта возвращается. Вы могли бы попробовать SELECT DISTINCT status С вашего стола, но это только получает значения состояния в настоящее время используется, которые могут быть не все значения в перечислении. Однако если вы сохраняете значения в таблице подстановки, их легко запрашивать, сортировать и т. д.

Я не большой поклонник перечисления, как вы можете сказать. : -)

то же самое относится к проверочным ограничениям, которые просто сравнивают столбец с фиксированным набором значений. Хотя MySQL не поддерживает проверочные ограничения в любом случае.

вот статья о сравнение скорости перечисления. Может быть, это дает некоторые намеки. ИМХО следует ограничиться использованием в фиксированном списке строк ("да/нет", "Ребенок / Взрослый"), что с вероятностью 99% не изменится в будущем.

перечисления в mysql плохи по уже объясненным причинам.
Я могу добавить следующий факт: Enum не обеспечивает никакой проверки на стороне сервера. Если вы вставляете строку со значением, которое не выходит из определения перечисления, вы получите хорошее или нулевое значение в БД, в зависимости от нулевой способности объявления поля перечисления.

моя точка зрения о tinyints:
- перечисления ограничены до 65535 значений
- если вам не нужно больше 256 значений, tinyint займет меньше места для каждой строки, и его поведение гораздо более "более".

Если у вас есть много данных в вашей БД ( больше данных, чем у вас есть ОЗУ), и вы перечисляете значения никогда не изменится, я бы пошел с перечислением, а не присоединиться. Это должно быть быстрее.
Подумайте об этом, в случае соединения вам нужен индекс для вашего внешнего ключа и индекс для вашего первичного ключа в другой таблице. Как сказал Рихо, смотрите ориентиры.

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