Yii Framework

Лучше множественные статусы в БД хранить в INT или в VARCHAR? (Понятно что не в ENUM)

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

За VARCHAR:
1. Проще писать миграции.
2. Не нужно каждый раз лазить в код, чтобы понять что означает та или другая цифра.
3. Можно сделать запрос типа "SELECT * FROM task GROUP BY status" и сразу прочитать результат "глазами", без заглядывания в код.

За INT:
1. Меньше места занимает.
2. Считается производительнее.

Ваше мнение?

За VARCHAR.

1. Проще писать миграции.

Почему? По-моему, одинаково. Конечно, если для int-ов завести константы также, как и для строк.

Ещё аргумент за int подкину. Если статусы по смыслу означают уровни, например, уровни логирования, то int позволяет делать запросы вида WHERE level > Log::LEVEL_INFO.

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

И вот ты делаешь запросы, где меняешь старый статус на новый.

В случае строк просто пишешь значение старое и новое. Было 'active', стало 'approved'. А в цифрах как? Константы будут отражать только текущее значение в коде. Если просто цифры писать без констант - то код нечитаем.

Так константы копируются в миграцию.

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

А просветите, чем ENUM не угодил?

Да, в общем-то ничем. Выбирали из varchar и int просто.

anton_z писал(а): ↑2019.07.04, 13:23 А просветите, чем ENUM не угодил?

Частая ситуация что список в enum начинает расширятся. Например было 3 категории "на века", а сегодня их уже 20. Добавлять очень неудобно.

anton700 писал(а): ↑2019.07.05, 09:49

anton_z писал(а): ↑2019.07.04, 13:23 А просветите, чем ENUM не угодил?

Частая ситуация что список в enum начинает расширятся. Например было 3 категории "на века", а сегодня их уже 20. Добавлять очень неудобно.

Ну не знаю, за то ENUM дает гарантию, что ничего постороннего (несуществующег статуса) в кортеже не будет, гарантирует целостность.

anton_z писал(а): ↑2019.07.05, 14:28 Ну не знаю, за то ENUM дает гарантию, что ничего постороннего (несуществующег статуса) в кортеже не будет, гарантирует целостность.

Гарантирует... молча вписывая 0 вместо статуса?

ElisDN писал(а): ↑2019.07.05, 16:17

anton_z писал(а): ↑2019.07.05, 14:28 Ну не знаю, за то ENUM дает гарантию, что ничего постороннего (несуществующег статуса) в кортеже не будет, гарантирует целостность.

Гарантирует... молча вписывая 0 вместо статуса?

Ошибку выдает. Strict SQL_MODE в помощь.

anton_z писал(а): ↑2019.07.06, 01:46 Ошибку выдает. Strict SQL_MODE в помощь.

Тогда нормально.

вообще-то unsigned tiny int
https://dev.mysql.com/doc/refman/8.0/en ... types.html

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

samdark правильно пишет - делаешь константы и всё.

я на мультиязычных делаю классы вроде
/**
@property-read int id
@property-read string name
*/
class Status {
const STATUS_OK=1;
const STATUS_FAIL=2;
public static function all() { return [Status, Status...] }
public static function toArray() { список статусов с переводимыми названиями }
}

VARCHAR - для человека
Для БД - INT

Если проект по количеству данных "не большой", то можно сделать для человека
Если данных будет много - INT

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

Если же быстродействие начинает хромать, для выборок по битовому статусу, то - вводятся виртуальные колонки с индесками для основных состояний, и обращение к ним, вместо реальной, инкапсулируется.

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

ENUM же забраковал для себя так давно, что и забыл уже аргументы

Nex-Otaku писал(а): ↑2019.07.02, 10:59 Лучше множественные статусы в БД хранить в INT или в VARCHAR? (Понятно что не в ENUM)

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

За VARCHAR:
1. Проще писать миграции.
2. Не нужно каждый раз лазить в код, чтобы понять что означает та или другая цифра.
3. Можно сделать запрос типа "SELECT * FROM task GROUP BY status" и сразу прочитать результат "глазами", без заглядывания в код.

За INT:
1. Меньше места занимает.
2. Считается производительнее.

Ваше мнение?

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