Здравствуйте. Задача: нужно вывести продукты по выбранным свойствам. Такое наверное встречали на каждом сайте, где присутствует фильтр.

Таблицы:

1) Продукты - собственно сами продукты.





2) Имена свойств(к примеру "тип", "диагональ", "формат экрана").




3) Значения свойств(к примеру "жк-телевизор", "22", "16:9" соответственно).

`ff_id` - связка с test_feature_fields.ff_id




4) Сопоставления продуктов с парами свойство - значение свойства

p_id - связка с test_products.p_id
ff_id - связка с test_feature_fields.ff_id
fv_id - связка с test_feature_values.fv_id





INSERT:



В данном примере допустим я выбираю продукт, у которого тип=знач1 и цвет=знач3 и должен вывести "товар1".
Много чего перепробовал, пробовал даже INTERSECT, который, прогуглив, нашёл у вас на форуме. Долго с ним мучался, а потом прочитал вверху форума SQLite :)

debloggerCREATE TABLE `product` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`val_id` int(11) NOT NULL default 1,
`product_name` varchar(255) NOT NULL,
PRIMARY KEY (`id`)
);

CREATE TABLE `product_key` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`key_name` varchar(255) NOT NULL,
PRIMARY KEY(`id`)
);

CREATE TABLE `product_val` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`key_name_id` int(11) NOT NULL,
`val_name` varchar(255) NOT NULL,
PRIMARY KEY(`id`)
);
Данный способ мне не подходит, так как values - конкретные значения, которые должны храниться в базе данных. Иначе мне придется на сайте в фильтре либо самому эти значения вручную вставлять для каждого свойства, либо выбирать из product_val distinct-ом `val_name`, что я считаю не есть хорошо.

debloggerОсобенно впечатлил мост

`pf_id` int(11) NOT NULL AUTO_INCREMENT,
`p_id` int(11) NOT NULL,
`ff_id` int(11) NOT NULL,
`fv_id` int(11) NOT NULL

Простите, я на самом деле немного подругому называю, просто хотел сократить названия полей, думал они будут интуитивно понятны, так как являются абревиатурами от F eature_ f ields(ff), F eature_ v alues(fv).
debloggerВы потеряете время на расшифровке в стопицот раз больше чем сэкономите на набивке кода.

Незнаю, я очень быстро привык, ну не все как я конечно..
debloggerЯ понимаю у многих с клавой нет дружбы, я и сам печатаю тремя с половиной пальцами, но опыт говорит что лучше назвать поле Наименование_Категории и Код_Наименования_Категории чем полчаса скрипеть мозгами и листать структуру чтобы найти n_cat или nm_cat_id

Не, я слепой печатник :)

Arhat109ExOLiNe,

1. Вставки (пакет ваших инсертов) - в боевом применении надо заворачивать в транзакцию. Это раз. Особенно, если учесть, что "юзверь" часто один - апач.

2. Посмотрите поиском в направлении EAV. Уже есть мноо примеров КАК выбирать и по одному и по набору параметров.
1. Учту, просто я до этого никогда не использовал транзакции.
2. Посмотрел. Сплошь везде только "альтернативы EAV", как будто этот способ самый худший :( Ну буду дальше искать. Однако буду очень рад помощи полезными ссылками, если у кого есть под рукой :)

Обнаружил один способ, который работает:


Это для двух свойств. SELECT'ом проходимся и выискиваем поля с одним значением поля, а LEFT JOIN'ом проходимся и находим поля со вторым значением, затем ON pf.`p_id`=pff.`p_id` выбирает только те продукты, у которых есть оба этих свойства.
Проблема:
Чем больше свойств - тем больше left-join'ов. Если выбранных свойств будет штук 50, то я думаю запрос будет выглядеть не очень красиво, не говоря уже о его производительности при постоянном перепросмотре всей таблицы.

MasterZiv4) Сопоставления продуктов с парами свойство - значение свойства

p_id - связка с test_products.p_id
ff_id - связка с test_feature_fields.ff_id
fv_id - связка с test_feature_values.fv_id

CREATE TABLE `test_product_features` (
`pf_id` int(11) NOT NULL AUTO_INCREMENT,
`p_id` int(11) NOT NULL,
`ff_id` int(11) NOT NULL,
`fv_id` int(11) NOT NULL
) AUTO_INCREMENT=1;


Два поля лишние, должно быть только

`p_id` int(11) NOT NULL,
`fv_id` int(11) NOT NULL

и они должны быть в PK.

ff_id - есть уже в test_feature_values, а суррогатный ключ pf_id просто тут не нужен, он не будет использоваться.

Даже если ты оставишь эти поля, тебе нужно ещё добавить UNIQUE CONSTRAINT по продукту и свойству, иначе можно будет создавать несколько значений одного свойства.

Хотя ff_id можно и оставить, как раз для такого констрейнта.

Вот если бы в test_feature_values не было бы суррогатного ключа, а был бы составной из feature & value_id, можно было бы просто
сделать FK на составной PK в test_feature_values.

И я не понял, в чём вопрос собственно ?
Нет, я просто не стал сюда писать что у меня составной ключ на (p_id, ff_id), я посчитал это не нужным. Суррогатный ключ уберу, ок. Просто привык уже к каждой таблице привязывать авто_инкремент, плохая привычка.
Вопрос собственно: как составить оптимальный запрос на выборку продуктов с неограниченным количеством выбранных свойств?

Cygapb-007так?

Нет. При выборе пары(ff_id-fv_id) 1-2, 2-3 выводит два товара, хотя должен вернуть NULL

Вроде бы нашел решение:




Производится поиск по таблице-связке всех возможных совпадений через ИЛИ. Потом полученные строки группируются по p_id и подсчитывается количество p_id из результата. Если count(p_id) равен количеству запрашиваемых из базы свойств - значит у продукта есть все запрашиваемые свойства. Но это конечно только подзапрос, но самый важный.

debloggerВаш клиент не умеет редактировать рекордсеты или вы о чем вообще пишите?

Как раз таки о том и речь, чтобы клиент мог свободно добавлять/удалять/редактировать values, чтобы они потом по всему сайту где это требуется выпадали списком. А когда значения хранятся как просто строковые, без привязки id - мне кажется тогда уж можно вобще всё упростить до одного текстового поля description, а фильтр тогда сделать просто LIKE '%что-то%'

debloggerСделайте своего клиента который разберется в матерях-дочках или как там, в InnoDB fk профтыкайте ради integrity. Даже VIEW's можно сделать редактируемым, а тут понимаешь полтора справочника и уже проблемы.
Про VIEW почитаю.