Страница 1 из 1

Множественные статусы: INT или VARCHAR?

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

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

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

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

Ваше мнение?

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.07.02, 11:50
ElisDN
За VARCHAR.

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.07.02, 14:37
samdark
1. Проще писать миграции.
Почему? По-моему, одинаково. Конечно, если для int-ов завести константы также, как и для строк.

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

Re: Множественные статусы: INT или VARCHAR?

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

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

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

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.07.02, 17:01
samdark
Так константы копируются в миграцию.

Re: Множественные статусы: INT или VARCHAR?

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

Re: Множественные статусы: INT или VARCHAR?

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

Re: Множественные статусы: INT или VARCHAR?

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

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.07.05, 09:49
anton700
anton_z писал(а):
2019.07.04, 13:23
А просветите, чем ENUM не угодил?
Частая ситуация что список в enum начинает расширятся. Например было 3 категории "на века", а сегодня их уже 20. Добавлять очень неудобно.

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.07.05, 14:28
anton_z
anton700 писал(а):
2019.07.05, 09:49
anton_z писал(а):
2019.07.04, 13:23
А просветите, чем ENUM не угодил?
Частая ситуация что список в enum начинает расширятся. Например было 3 категории "на века", а сегодня их уже 20. Добавлять очень неудобно.
Ну не знаю, за то ENUM дает гарантию, что ничего постороннего (несуществующег статуса) в кортеже не будет, гарантирует целостность.

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.07.05, 16:17
ElisDN
anton_z писал(а):
2019.07.05, 14:28
Ну не знаю, за то ENUM дает гарантию, что ничего постороннего (несуществующег статуса) в кортеже не будет, гарантирует целостность.
Гарантирует... молча вписывая 0 вместо статуса?

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.07.06, 01:46
anton_z
ElisDN писал(а):
2019.07.05, 16:17
anton_z писал(а):
2019.07.05, 14:28
Ну не знаю, за то ENUM дает гарантию, что ничего постороннего (несуществующег статуса) в кортеже не будет, гарантирует целостность.
Гарантирует... молча вписывая 0 вместо статуса?
Ошибку выдает. Strict SQL_MODE в помощь.

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.07.06, 11:12
ElisDN
anton_z писал(а):
2019.07.06, 01:46
Ошибку выдает. Strict SQL_MODE в помощь.
Тогда нормально.

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.08.14, 19:31
uEhlO4a
вообще-то 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() { список статусов с переводимыми названиями }
}

Re: Множественные статусы: INT или VARCHAR?

Добавлено: 2019.09.12, 15:38
skynin
VARCHAR - для человека
Для БД - INT

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

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

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

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

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

Re: Множественные статусы: INT или VARCHAR?

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

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

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

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

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