Как лучше организовать таблицы параметров товара?

Question

[k-2]

Как будет правильнее и производительнее составить таблицы.
Учитываю производительность при поиске по value_params_char

Answer 1

[xmoonlight]

Первый способ + уникальные индексы на все id и name_params и на value_params_char.
Но лучше подумать про хранение в JSON в mysql >=5.5 и как-то пересмотреть текущую структуру.

Comments

[k-2]

В mysql 5.5 можно осуществлять поиск по содержимому в json?

[xmoonlight]

k-2: да.

[k-2]

xmoonlight: Имеется ввиду это?
SELECT `id` , `attribs_json`
FROM `products`
WHERE `attribs_json` REGEXP '"1":{"value":[^"3"$]'

My data is:

{"feature":{"1":{"value":"["2","3"]"},
"2":{"value":["1"]},
"5":{"value":""},
"3":{"value":["1"]},
"9":{"value":""},
"4":{"value":"\u0633\u0627\u062a\u0646"},
"6":{"value":""},
"7":{"value":""},
"8":{"value":""}
},
"show_counter":"0",
"show_counter_discount":""
}}

[xmoonlight]

k-2: имеется ввиду официальная возможность поиска по JSON в mysql.

[k-2]

xmoonlight: Да, спасибо. Нашел про это тут dev.mysql.com/doc/refman/5.7/en/json-search-functi...

[k-2]

xmoonlight: еще вот тут кое что прочитал https://habrahabr.ru/post/279155/

[xmoonlight]

k-2: я могу сказать, что скорость поиска по полям json и по обычным - одинаковая. т.к. формирование индексов в базе - одинаковое у них.

[k-2]

xmoonlight: версия 5.7 нужна? у меня на xampp версия 5.6, типа данных json нет. а на сервере 5.7 там есть.

[xmoonlight]

k-2: а-а.. ну значит я подзабыл... наверное да, с 5.7 только ввели JSON

Answer 2

[Станислав Макаров]

То, что вы сейчас делаете - это EAV (Entity–attribute–value), можете гуглить по этому термину. А вообще советую переместить параметры товаров в документную базу (ибо EAV это костыль).

Comments

[k-2]

А почему костыль? проблема в чем заключается?

[Станислав Макаров]

k-2 в том, что вы используете реляционную модель не по назначению. EAV "разворачивает" вашу схему перпендикулярно, и вместо того, чтобы было по одному столбцу на каждое свойство товара (что невозможно в вашем случае по причине изменчивости свойств), у вас будет по одной ЗАПИСИ на каждое свойство каждого товара. Т.е. по сути это борьба с реляционной моделью, попытка получить от неё полу-структурированные, для чего не предназначена.

Это решение приемлемо для небольших объемов данных, или если поддерживать другую СУБД значительно сложнее, чем поддерживать EAV в реляционной.

[k-2]

Станислав Макаров:
"EAV разворачивает вашу схему перпендикулярно, и вместо того, чтобы было по одному столбцу на каждое свойство товара, у вас будет по одной ЗАПИСИ на каждое свойство каждого товара. "
Ну так для этого и создается такая структура. И есть тому несколько причин. Например свойства товаров могут быть разные(у какого то товара есть только цвет, а у другого есть только размер, но нет цвета). А так же может быть когда у одного свойства есть сразу несколько значений(например цвет может быть одновременно красный и черный. Или состав может быть коттон и полиэстер одновременно). Если в таблице товара прописать по свойству, то одновременно нельзя будет назначить несколько значений, или количество свойств и значений будет ограниченно(например у одного товара может быть не больше 8 свойств и у каждого свойства не более 5 значений). И это все будет записываться с БД, даже если этих свойств и значений нет, то они будут писаться пустыми строками.

[k-2]

Станислав Макаров: Таким образом при 8 свойствах и 5 значениях у каждого товара, в таблице товара будет 40 строк только на свойства и значения, даже если их у этого товара нет

[Станислав Макаров]

k-2 я прекрасно понимаю зачем нужен EAV конкретно вам, и зачем он нужен в принципе. Более того, я год назад уже отвечал на такой же вопрос: Как спроектировать базу данных? . И вот еще на один подобный Как добавить товар в корзину? . Я вам говорю, что если вы еще в начале проекта, то возможно стоит принять решение использовать для характеристик о товарах документную базу. Если это невозможно, то вы нагуглите массу информации по EAV.