Множественные статусы: INT или VARCHAR?
Множественные статусы: INT или VARCHAR?
Лучше множественные статусы в БД хранить в INT или в VARCHAR? (Понятно что не в ENUM)
Я сам пробовал оба варианта, какой мне больше по итогам понравился я указал в опросе. Интересно, что разные разработчики делают разный выбор, хотелось бы услышать больше аргументов с той и другой стороны )
За VARCHAR:
1. Проще писать миграции.
2. Не нужно каждый раз лазить в код, чтобы понять что означает та или другая цифра.
3. Можно сделать запрос типа "SELECT * FROM task GROUP BY status" и сразу прочитать результат "глазами", без заглядывания в код.
За INT:
1. Меньше места занимает.
2. Считается производительнее.
Ваше мнение?
Я сам пробовал оба варианта, какой мне больше по итогам понравился я указал в опросе. Интересно, что разные разработчики делают разный выбор, хотелось бы услышать больше аргументов с той и другой стороны )
За VARCHAR:
1. Проще писать миграции.
2. Не нужно каждый раз лазить в код, чтобы понять что означает та или другая цифра.
3. Можно сделать запрос типа "SELECT * FROM task GROUP BY status" и сразу прочитать результат "глазами", без заглядывания в код.
За INT:
1. Меньше места занимает.
2. Считается производительнее.
Ваше мнение?
Re: Множественные статусы: INT или VARCHAR?
За VARCHAR.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Множественные статусы: INT или VARCHAR?
Почему? По-моему, одинаково. Конечно, если для int-ов завести константы также, как и для строк.1. Проще писать миграции.
Ещё аргумент за int подкину. Если статусы по смыслу означают уровни, например, уровни логирования, то int позволяет делать запросы вида WHERE level > Log::LEVEL_INFO.
Нравится Yii? Давайте сделаем его лучше!.
Re: Множественные статусы: INT или VARCHAR?
А представь миграцию, где у тебя половина статусов поменялась. Часть добавили новых, часть оставили старых, какие-то объединили. Не такая уж редкая ситуация.
И вот ты делаешь запросы, где меняешь старый статус на новый.
В случае строк просто пишешь значение старое и новое. Было 'active', стало 'approved'. А в цифрах как? Константы будут отражать только текущее значение в коде. Если просто цифры писать без констант - то код нечитаем.
И вот ты делаешь запросы, где меняешь старый статус на новый.
В случае строк просто пишешь значение старое и новое. Было 'active', стало 'approved'. А в цифрах как? Константы будут отражать только текущее значение в коде. Если просто цифры писать без констант - то код нечитаем.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Множественные статусы: INT или VARCHAR?
Так константы копируются в миграцию.
Нравится Yii? Давайте сделаем его лучше!.
Re: Множественные статусы: INT или VARCHAR?
varchar - лучше. Когда делаешь запросы к базе напрямую, посмотреть что нибудь, удобнее понимать что происходит, чем сверятся со списком констант.
Re: Множественные статусы: INT или VARCHAR?
А просветите, чем ENUM не угодил?
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Множественные статусы: INT или VARCHAR?
Да, в общем-то ничем. Выбирали из varchar и int просто.
Нравится Yii? Давайте сделаем его лучше!.
Re: Множественные статусы: INT или VARCHAR?
Ну не знаю, за то ENUM дает гарантию, что ничего постороннего (несуществующег статуса) в кортеже не будет, гарантирует целостность.
Re: Множественные статусы: INT или VARCHAR?
вообще-то 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() { список статусов с переводимыми названиями }
}
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?
VARCHAR - для человека
Для БД - INT
Если проект по количеству данных "не большой", то можно сделать для человека
Если данных будет много - INT
Я часто, и на текущем проекте, вообще использую статусы как битовые поля, в которых более старший бит отвечает за следующее состояние для основного, самого частого сценария смены состояний.
в итоге, в случае потребности в расширении количества состояний, используются комбинации бит
При этом остаются возможными и запросы вида level > Log::LEVEL_INFO
Но для этого надо провести анализ бизнес области, чтобы выявить составляющие состояний и этот основной сценарий.
Если же быстродействие начинает хромать, для выборок по битовому статусу, то - вводятся виртуальные колонки с индесками для основных состояний, и обращение к ним, вместо реальной, инкапсулируется.
VARCHAR выбирать нужно тогда, когда анализ состояния невозможен или избыточен, когда интуиция подсказывает что в будущем состояний и их подвидов может появиться неизвестное количество, или когда состояния будут появляться в системе в процессе ее работы, и никак неизвестны на этапе разработки
ENUM же забраковал для себя так давно, что и забыл уже аргументы
Для БД - INT
Если проект по количеству данных "не большой", то можно сделать для человека
Если данных будет много - INT
Я часто, и на текущем проекте, вообще использую статусы как битовые поля, в которых более старший бит отвечает за следующее состояние для основного, самого частого сценария смены состояний.
в итоге, в случае потребности в расширении количества состояний, используются комбинации бит
При этом остаются возможными и запросы вида level > Log::LEVEL_INFO
Но для этого надо провести анализ бизнес области, чтобы выявить составляющие состояний и этот основной сценарий.
Если же быстродействие начинает хромать, для выборок по битовому статусу, то - вводятся виртуальные колонки с индесками для основных состояний, и обращение к ним, вместо реальной, инкапсулируется.
VARCHAR выбирать нужно тогда, когда анализ состояния невозможен или избыточен, когда интуиция подсказывает что в будущем состояний и их подвидов может появиться неизвестное количество, или когда состояния будут появляться в системе в процессе ее работы, и никак неизвестны на этапе разработки
ENUM же забраковал для себя так давно, что и забыл уже аргументы
Не желайте странного, и не будет у вас головной боли чтобы достичь этого странного.
Тем более что окажется что оно вам и не нужно было, странное это.
Тем более что окажется что оно вам и не нужно было, странное это.
Re: Множественные статусы: INT или 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. Считается производительнее.
Ваше мнение?
Да его сложнее расширять, поэтому если подразумевается частое расширение списка то не вариант.
Но зато серьезный плюс - гарантированный список вариантов, что обеспечивает более надежную связь с кодом.