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

Обсуждаем, как правильно строить приложения
Ответить

Статусы хранить в INT или в VARCHAR?

INT
5
56%
VARCHAR
4
44%
 
Всего голосов: 9

Nex-Otaku
Сообщения: 831
Зарегистрирован: 2016.07.09, 21:07

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

Сообщение Nex-Otaku »

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

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

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

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

Ваше мнение?
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

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

Сообщение samdark »

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

Ещё аргумент за int подкину. Если статусы по смыслу означают уровни, например, уровни логирования, то int позволяет делать запросы вида WHERE level > Log::LEVEL_INFO.
Nex-Otaku
Сообщения: 831
Зарегистрирован: 2016.07.09, 21:07

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

Сообщение Nex-Otaku »

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

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

В случае строк просто пишешь значение старое и новое. Было 'active', стало 'approved'. А в цифрах как? Константы будут отражать только текущее значение в коде. Если просто цифры писать без констант - то код нечитаем.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

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

Сообщение samdark »

Так константы копируются в миграцию.
anton700
Сообщения: 2
Зарегистрирован: 2019.07.03, 20:41

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

Сообщение anton700 »

varchar - лучше. Когда делаешь запросы к базе напрямую, посмотреть что нибудь, удобнее понимать что происходит, чем сверятся со списком констант.
anton_z
Сообщения: 483
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z »

А просветите, чем ENUM не угодил?
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

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

Сообщение samdark »

Да, в общем-то ничем. Выбирали из varchar и int просто.
anton700
Сообщения: 2
Зарегистрирован: 2019.07.03, 20:41

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

Сообщение anton700 »

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

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

Сообщение anton_z »

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

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

Сообщение ElisDN »

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

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

Сообщение anton_z »

ElisDN писал(а): 2019.07.05, 16:17
anton_z писал(а): 2019.07.05, 14:28 Ну не знаю, за то ENUM дает гарантию, что ничего постороннего (несуществующег статуса) в кортеже не будет, гарантирует целостность.
Гарантирует... молча вписывая 0 вместо статуса?
Ошибку выдает. Strict SQL_MODE в помощь.
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

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

Сообщение ElisDN »

anton_z писал(а): 2019.07.06, 01:46 Ошибку выдает. Strict SQL_MODE в помощь.
Тогда нормально.
uEhlO4a
Сообщения: 70
Зарегистрирован: 2017.08.12, 19:19

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

Сообщение 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() { список статусов с переводимыми названиями }
}
skynin
Сообщения: 400
Зарегистрирован: 2017.12.12, 10:09

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

Сообщение skynin »

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

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

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

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

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

ENUM же забраковал для себя так давно, что и забыл уже аргументы :)
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
yan
Сообщения: 942
Зарегистрирован: 2011.03.23, 09:28
Откуда: Уфа

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

Сообщение 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 сочетает преимущества обоих вариантов, но почему-то принципиально исключен
Да его сложнее расширять, поэтому если подразумевается частое расширение списка то не вариант.
Но зато серьезный плюс - гарантированный список вариантов, что обеспечивает более надежную связь с кодом.
Ответить