Стоит ли использовать тип Enum в MySql для Yii2?

Question

[AlexKuznec]

Использую Yii2 и MySql.
Хочу добавить в таблицу "техническое" поле type - тип записи, чтобы можно было по разному интерпретировать данные (вроде такая практика не приветствуется, но я пока хочу за один проход по одной таблице выбрать все нужные мне записи, а потом в виде по разному отображать их в зависимости от type).

Тип Enum кажется привлекательным, но, как я понял, при попытке добавить туда новый тип записи, придется запускать изменение всей таблицы.
Альтернатива - однобайтовый tinyint и создание в коде именованных констант, чтобы не запутаться в цифрах. Плюс миграции останутся универсальными.

Может быть есть еще какие-то варианты?

Answer 1

[Максим Федоров]

Для решения Вашей задачи Вы можете использовать:
1. Enum - сделает содержание колонки более понятный, в отличие от хранение данных в виде числа, при приблизительно тех же ресурсо-затратах. Но стоит понимать что его использование на больших объемах данных действительно приведет к приличным временным затратам, в случае необходимости изменения списка значений. Другой вопрос насколько часто Вы планируете это делать и какое количество данных будет храниться? Кроме того нужно понимать что в случае MySQL нет возможности сделать один общий список для нескольких таблиц. Поэтому если планируется его использовать сразу в нескольких таблицах - это придет к дублированию данных.
2. Тип в виде числа - сделает содержание колонки не понятным для сторонних разработчиков. Например, тип с значением 7 ничего не сможет сказать о своем назначении. А порой возникают задачи, которые необходимо реализовывать на уровне базы, и в этом случае искать в коде что такое 7 крайне не удобно.
3. Тип в виде отдельной таблицы - Вы можете все типы вынести в отдельную таблицу, и использовать в своих записях ссылку на нее. Этот вариант решит некоторые проблемы предыдущих, но стоит понимать что такой подход может создать в базе кучу по сути неиспользуемых таблиц, что тоже не есть хорошо.

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

Comments

[AlexKuznec]

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

Answer 2

[Евгений Вольф]

Ещё есть вариант ссылки на другую таблицу, с набором заготовленных вариантов... Мы для себя выбрали ENUM, правда не в MySQL, а в PG, но сути дела это особо не меняет. Если внезапно нужно изменить таблицу (в PG нужно будет менять не таблицу, а ранее созданный тип данных) и добавить новый тип - это делается без особых проблем, т.к. у базы и проекта есть администраторы, контентщики и пр. обслуживающий персонал.

Почему ENUM? Мы руководствовались тем, он более читаем в результатах запроса и... В вашем примере - Вам не нужно изменять базу, но нужно менять код, в нашем случае - исключается возможность создания записи неизвестного типа, в том числе, при "ручном" изменении БД.

В общем, на мой взгляд - вопрос больше личных предпочтений, я Вам озвучил наши :)