Должен ли я реализовать нормализацию чтения базы данных (с помощью таблиц соединения) или использовать тип ENUM для статических или динамических данных?
Например:
У меня есть таблица USER с user_status. Должен ли я создать таблицу status или создать список ENUM со статусами?
Спасибо Г
ИМХО, расширение enum значительно упрощает встраивание семантики в таблицу, а также повышает эффективность за счет:
Единственные недостатки, о которых я знаю, это
ХТН
C.
ENUM. Во-первых, все столбцы ENUM могут принимать специальное неизвестное значение пустой строки (в дополнение к NULL, если это разрешено); кроме того, это значение будет использоваться для любого присвоения недопустимого значения, если только не используется строгий режим SQL. Это может привести к непреднамеренной несогласованности базы данных; Кроме того, если в списке ENUM имеется явное пустое строковое значение, это может привести к огромной путанице (поскольку необходимо проверить числовое значение, чтобы определить, какой тип пустой строки хранится).
- person eggyal; 25.04.2013
ENUM. В руководстве приводится хороший пример списка ENUM ('0','1','2'): Если вы сохраняете 2, оно интерпретируется как значение индекса и становится '1' (значение с индексом 2). Если вы сохраняете '2', оно соответствует значению перечисления, поэтому оно сохраняется как '2'. Если вы сохраняете '3', оно не соответствует никакому значению перечисления, поэтому оно рассматривается как индекс и становится '2' (значение с индексом 3).
- person eggyal; 25.04.2013
ENUM может вызвать путаницу в контексте сортировки, поскольку значения сортируются в соответствии с их положением в списке ENUM (в то время как можно ожидать, что значения будут отсортированы лексикографически). Хотя я бы не стал заходить так далеко, как 8 причин, почему тип данных ENUM в MySQL является злом, я определенно думаю, что его статью стоит прочитать, чтобы понять проблемы; и, учитывая, что объединение должным образом проиндексированных таблиц должно быть столь же (если не более) эффективным, чем ENUM, я не вижу в этом реальных преимуществ.
- person eggyal; 25.04.2013
implicit conversion to numeric values - опять не удалось воспроизвести. Попытка вставить целочисленное значение в столбец enum дала ошибку # 1064, когда я попытался это сделать.
- person symcbean; 07.11.2013
can cause confusion in sorting - все известные мне языки с поддержкой enum либо используют порядок объявления в качестве индикатора последовательности (C, Fortran, Java, MySQL), либо рассматривают значения как чисто непорядковые (т.е. номинальные). Если вам явно нужно упорядочение на основе метки, а не ее внутреннего представления, это не сложно (ORDER BY concat(enumd)) - откровенно говоря, любой, кто не знает, как их инструменты управляют вводом текста, заслуживает всего, что они получают;)
- person symcbean; 07.11.2013
Другая вещь, которую следует учитывать...
Перечисление может быть обновлено только путем изменения структуры базы данных в другом месте, где связанная таблица допускает динамическое создание записи.
Это зависит от архитектуры и многих других факторов.
Например, вы не разрешаете чтение/запись данных, кроме как с использованием хранимых процедур. В этом случае вы можете свободно использовать тип данных «tinyint». Если вы разрешаете чтение/запись с прямыми запросами, лучше использовать ограничение, то есть ENUM, чтобы избежать неправильных статусов (если, конечно, пользовательский интерфейс или серверная часть могут поставить этот «неправильный» статус).
С другой стороны (и это возможно) могут быть изменения в потоке данных и, возможно, вам нужно будет добавить новые статусы. В этом случае вам потребуется: 1) ничего не делать, если у вас статический тип данных; 2) измените, если у вас есть ENUM.
Итак... мой ответ: это зависит от вашего приложения и ваших требований.
