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

Question

[ta4]

Необходимо в БД хранить характеристики товаров.
Вот 2 таблицы

Т.е. есть 2 таблицы.
Первая таблица "характеристика", вторая возможные значения.
Основная проблема в том, что характеристики бывают нескольких типов. Для этого добавили в таблицу характеристик поле "type" (тип может быть 'checkbox','radiobutton','multiselect','text').
К примеру, если характеристика имеет тип checkbox (например "GPS" имеет значение либо true, либо false), то приходится в таблице значений хранить true и false для этой характеристики. Таких характеристик очень много и для каждой мы храним true и false в таблице значений. Как можно этого избежать, либо это нормально?

Answer 1

[Артём Каретников]

Доброго. Что ж тут думать, это ж не шахматы. Вот у вас есть условно 1000 свойств товара. У некого товара из них заполнено всего 3. Остальные хранить пустыми, разумеется, не нужно.

Что нужно - а очень даже просто, следите за рукою:

Берем id товара, условно 1189. Берем три id свойств товара, 11, 22, 33. Заводим таблицу с полями:

Id_ProductProperty int
Id_Product int
Id_Property int

И вот сюда аккуратно кладем:

1 1189 11
2 1189 22
3 1189 33

Всё. Есть у вас свойство - оно в этой таблице, а значит, True. Нет свойства - нет его в этой таблице.
Таблица полностью интовая, еще индексы ставите, как положено, на join поля - и все летает.

Comments

[ta4]

это все понятно, суть в том, что еще есть у каждого свойства возможные значения. У многих свойств значения будут одинаковыми (true/false). Вопрос в том, нормально ли будет хранить много повторяющихся вариантов в таблице (хотя по-другому видимо никак)

[Артём Каретников]

Если это инты - то хоть обхранитесь.

Answer 2

[sim3x]

https://dev.mysql.com/doc/refman/5.0/en/enum.html

field_type ENUM('checkbox','radiobutton','multiselect','text')

// у енума в 4.х были вопросы с производительностью

или
field_type int(1)
в классе модели указать соотвествие

1=> 'checkbox', 2 => 'radiobutton',

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

Answer 3

[Кирилл Пензин]

Юзай типы данных, Люк. Есть ведь множество типов данных у мускуля. По факту нужна одна таблица, в которой перечислены значения характеристик товара. Максимум, можно создать доп. таблицы, описывающие набор хар-к каждой категории товаров, если варианты значений там сильно различаются.

Comments

[ta4]

Как при этом организовать структуру таблиц?

[Кирилл Пензин]

ta4: Таблица "Карточка товара". В ней перечисляются все необходимы характеристики, а их значения описываются стандартными типами(их более чем достаточно обычно, либо вы слишком усложнили модель). В крайнем случае можно определить наборы хар-к, разбив на категории товары тогда получится таблица "карточка товара", в которой описаны общие для всех категорий хар-ки, enum-ом описаны варианты категорий и id записи в таблице категории. В таблице "категория" должны храниться ваши наборы уникальных для данной категории значений и id определённой записи(как вы понимаете это ключ, по которому можно бувдет извлечь характеристики).

[Кирилл Пензин]

ta4: связь между "карточкой товара" и "категорией" один-к-одному.

[ta4]

Кирилл Пензин: первый вариант не подходит, а второй приблизительно как у меня сейчас реализовано. вот есть у нас "набор характеристик" для категории. А сами варианты значений мы должны хранить в отдельной таблице. (например характеристика "Операционная система", в таблице значений хранятся возможные значения "android", "ios", "wp", а есть еще такие характеристики как GPS, Bluetooth, в таблице значений хранятся true и false для каждой из них, вот я думаю можно ли как-то избежать повторения true и false для таких характеристик?)

[Кирилл Пензин]

ta4: вы для каждой характеристики отдельно храните набор значений? 0о сссударь... Я промолчу. Вы просто в таблице "набор характеристик" сразу задайте весь этот набор и опишите варианты значений(потворяю: ЧИТАЙТЕ ПРО ТИПЫ ДАННЫХ, ЗА ВАС УЖЕ ВСЁ ПРИДУМАЛИ). А каждая запись в данной таблице уже должна быть уникальным набором значений, если это описание товара. И никакой таблицы с "возможными значениями" не надо. Это какая-то дикость... Это всё равно что для того, чтобы заполнить анкету при приёме на работу вам пришлось бы собирать 10 разных бумажек, в каждой из которых бы было описание того, что вы можете и должны указать в каждом поле...

[sim3x]

ta4: ты уже задаешь вопросы, ответы на которые будут зависеть от фреймворка на котором идет реализация

[ta4]

Кирилл Пензин: да, возможно неверный у меня подход, но например если менеджер захочет добавить еще один вариант значения для характеристики ему придется править структуру БД? Возможно я чего-то не понимаю.

[Кирилл Пензин]

ta4: Вот как, тогда да. Надо будет доп. таблицу делать .