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

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

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

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

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

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

Сообщение Nex-Otaku » 2019.07.02, 10:59

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

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

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

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

Ваше мнение?


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

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

Сообщение samdark » 2019.07.02, 14:37

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

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

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

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

Сообщение Nex-Otaku » 2019.07.02, 16:26

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

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

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

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

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

Сообщение samdark » 2019.07.02, 17:01

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

anton700
Сообщения: 2
Зарегистрирован: 2019.07.03, 20:41

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

Сообщение anton700 » 2019.07.03, 21:51

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

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z » 2019.07.04, 13:23

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

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

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

Сообщение samdark » 2019.07.04, 19:31

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

anton700
Сообщения: 2
Зарегистрирован: 2019.07.03, 20:41

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

Сообщение anton700 » 2019.07.05, 09:49

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

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z » 2019.07.05, 14:28

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

Аватара пользователя
ElisDN
Сообщения: 5415
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

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

Сообщение ElisDN » 2019.07.05, 16:17

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

anton_z
Сообщения: 439
Зарегистрирован: 2017.01.15, 15:01

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

Сообщение anton_z » 2019.07.06, 01:46

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

Аватара пользователя
ElisDN
Сообщения: 5415
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

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

Сообщение ElisDN » 2019.07.06, 11:12

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

uEhlO4a
Сообщения: 62
Зарегистрирован: 2017.08.12, 19:19

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

Сообщение uEhlO4a » 2019.08.14, 19:31

вообще-то 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
Сообщения: 188
Зарегистрирован: 2017.12.12, 10:09

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

Сообщение skynin » 2019.09.12, 15:38

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

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

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

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

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

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

yan
Сообщения: 942
Зарегистрирован: 2011.03.23, 09:28
Откуда: Уфа

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

Сообщение yan » 2019.09.18, 00:31

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

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

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

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

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

Ответить