Как лучше спроектировать бд?

Question

[Vadim Stepanenko]

Задача следующая:
Имеется айтем, у которого может быть до 20 определенных опций (их их количество не изменится в будущем). Как хранить их в бд?
Варианта 3:
1. Создать отдельную таблицу, где будет 20 столбцов опций + столбец item_id. Есть опция вкл - пишем единицу, иначе ноль.
2. В общей таблице айтемов создать столбец и хронить там json доступных опций
3. Создать новую таблицу из 3 столбцов: id, item_id, option, и потом искать, есть ли запись с таким-то item_id и таким-то option

Первый способ не очень нравится ввиду большого количество столбцов.
Во втором варианте смущает json в бд. Плюс нужно будет кодировать и декодировать каждый раз.
Третий способ смущает тем, что таблица получится большой. Плюс, если у айтема будет пропадать опция (и будет удаляться запись из бд соответсовенно), то будет фрагментация таблицы.

Какой способ самый оптимальный?

Comments

[Дмитрий]

Смотря какие будут запросы, если опции не попадают в where то можно хранить вторым вариантом, иначе первый либо третий

[Дмитрий]

Ещё четвёртый вариант, на подобие второго, хранить сериализованный массив опции в поле

Answer 1

[xmoonlight]

Всего 3 таблицы:
2 таблицы: items и options
и одну "многие-ко-многим" (промежуточную): item_id, option_id (есть строка-"связка" - опция есть/включена у объекта)

Т.е. промежуточная таблица будет хранить только уникальные связи.
А быстрый поиск - можно делать как по опции, так и по айтему.
И добавить свойства или айтемы - проблем нет.

Comments

[Андрей Скоржинский]

Answer 2

[sim3x]

1
Разреженности таблицы не будет, тк у вас нет нула

EAV - для булевых оверкил
jsonb - оверкил по занимаемому месту