Как лучше хранить много чекбоксов в бд?

Question

[Narts]

На странице (товар) имеется 10 чекбоксов. Как лучше хранить их значения? Создавать для каждого чекбокса свой столбец в бд не вариант. Есть мысля перед сохранением в бд группировать все чекбоксы в один массив, и далее уже помещать в единую колонку, но может есть решения получше?

Comments

[stratosmi]

Что это?
Свойства товаров?

[Ярослав Иванов]

JSON

[Narts]

stratosmi, да

Answer 1

[Анна]

храните в виде числа.
010101, 1 - выбран, 0 - нет

Comments

[Александр]

а если сортировка чекбоксов измениться?

[stratosmi]

Александр,

а если сортировка чекбоксов измениться?

а вы зафиксируйте

[Сергей delphinpro]

stratosmi, а если добавить/удалить чекбоксы? А если выборку по ним делать? Очень ограниченное решение.

[stratosmi]

Сергей delphinpro,

а если добавить/удалить чекбоксы? А если выборку по ним делать?

А если - нет?
Ни выборки не надо. Ни чекбоксы не будут изменяться.

[Анна]

Александр, да какая разница. просто определенному разряду соответствие сделать с разрядом. и порядок не важен

Answer 2

[galliard]

Таблица формата
product_id | key | value
Можно не только чекбоксы, но и любые динамические свойства товара так хранить

Comments

[Beliyadm]

1000 товаров и по 10 свойств в каждом уже 10 тыщ записей.
Мне кажется что все-таки лучше хранить в JSON в той же таблице товаров (ну или связанной, если работать по нормализации) и выбирать поиском при необходимости можно так же из JSON строки, вроде с 5.7 Mysql это умеет с новыми функциями

[galliard]

Beliyadm, по моему в реляционной БД json выглядит как костыль. Если очень хочется jsona - выбирайте документо-ориентированную БД.

[Beliyadm]

galliard, Возможно, но держать стотысячные таблицы свойств зачастую на виртуальном хостинге тоже напряжно.
Да и JSON часто используется для фронта + функции работы с json в мускуле появились.

Опять же - зависит от задачи и мощностей. Если нет необходимости делать прямой поиск объектов по значениям этих чекбоксов - хранить смело как json строку в таблице товаров и парсить на фронте, минимальный объем базы и нагрузки.
Если же надо (сложный поиск с фронта по параметрам) - то уже по ситуации смотреть надо.

[stratosmi]

galliard,

по моему в реляционной БД json выглядит как костыль. Если очень хочется jsona - выбирайте документо-ориентированную БД.

Ради одного поля то?
Смотря как реализовано. В PostgreSQL тип данных JSONB далеко не костыль. Индексирование поддерживает. А что еще для счастия надо?

[Олег]

лучше 1 000 000 строк в таблице из 3х числовых ключей с индексами
чем 1000 записей с текстовым полем, в котором json

Answer 3

[Arman]

битовой маской можно попробовать, если другие не пошли варианты. или json тип поля заюзать