Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Фильтры товаров. запрос в бд
Форумы портала PHP.SU » » Вопросы новичков » Фильтры товаров. запрос в бд

Страниц (1): [1]
 

1. marat-dev - 14 Апреля, 2017 - 07:37:20 - перейти к сообщению
как лучше делать поиск товаров по фильтрам , использовать INNER JOIN ?
есть таблица фильтров отдельная , есть таблица товаров .
2. 3d_killer - 15 Апреля, 2017 - 23:02:00 - перейти к сообщению
да как раз это и нужно использовать
3. Vladimir Kheifets - 20 Апреля, 2017 - 08:52:57 - перейти к сообщению
marat-dev пишет:
как лучше делать поиск товаров по фильтрам , использовать INNER JOIN ?
есть таблица фильтров отдельная , есть таблица товаров .


Задача:
Из таблицы "product" выбирается значение из колонки "name",
если значение в колонке "product1" таблицы "product" равно значению
в колонке " filter1" таблицы "filter" и значение колонке " filter1" равно $fiter1

Можно сделать так:
1.
SELECT product.name FROM product, filter WHERE product.product1=filter.filter1 AND filter.filter1='$fiter1'

2.
SELECT name FROM product LEFT JOIN filter ON product.product1=filter.filter1 WHERE filter.filter1='$fiter1'

3.
SELECT name FROM product WHERE product1 IN (SELECT filter1 FROM filter WHERE filter1='$fiter1')
4. 3d_killer - 20 Апреля, 2017 - 18:39:39 - перейти к сообщению
вы своими лефт джоинами не путайте человека, если фильтров будет много и свойств много то все это будет висеть, уже проходили, использовать нужно только INNER JOIN уменьшая тем самым выборку
(Добавление)
вот тут разбирали тормоза
http://forum.php.su/topic.php?fo...80723#1458980723
5. Vladimir Kheifets - 21 Апреля, 2017 - 08:56:55 - перейти к сообщению
[quote=3d_killer]вы своими лефт джоинами не путайте человека, если фильтров будет много и свойств много то все это будет висеть, уже проходили, использовать нужно только INNER JOIN уменьшая тем самым выборку...

В моём случае из таблицы ContrysAllCodes по коду FIFA находится код ISO3166_1_Alpha_3 страны, а из таблицы iso_3_code название страны.

Я сравнил время выполнения 4 запросов в том числе INNER JOIN и LEFT JOIN.
Вы правы LEFT JOIN работает медленнее, но быстрее других:
SELECT iso_3_code.country_en FROM iso_3_code, ContrysAllCodes WHERE iso_3_code.iso3=ContrysAllCodes. ISO3166_1_Alpha_3 AND ContrysAllCodes.FIFA='RUS'


Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.0006 Sekunden.)
SELECT iso_3_code.country_en FROM iso_3_code, ContrysAllCodes WHERE iso_3_code.iso3=ContrysAllCodes. ISO3166_1_Alpha_3 AND ContrysAllCodes.FIFA='RUS'
country_en
Russian Federation

eige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.0007 Sekunden.)
SELECT country_en FROM iso_3_code WHERE iso3 IN (SELECT ISO3166_1_Alpha_3 FROM ContrysAllCodes WHERE ContrysAllCodes.FIFA='RUS')
country_en
Russian Federation


Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.0007 Sekunden.)
SELECT country_en FROM iso_3_code INNER JOIN ContrysAllCodes ON iso_3_code.iso3=ContrysAllCodes. ISO3166_1_Alpha_3 WHERE ContrysAllCodes.FIFA='RUS'
country_en
Russian Federation

Zeige Datensätze 0 - 0 (1 insgesamt, Die Abfrage dauerte 0.0008 Sekunden.)
SELECT country_en FROM iso_3_code LEFT JOIN ContrysAllCodes ON iso_3_code.iso3=ContrysAllCodes. ISO3166_1_Alpha_3 WHERE ContrysAllCodes.FIFA='RUS'
country_en
Russian Federation
6. Мелкий - 21 Апреля, 2017 - 11:29:17 - перейти к сообщению

Немецкая локаль? Я удивился


Сколько циклов проверяли? Результаты в рамках погрешности измерения.
Разница inner и left join в поведении, запросы не эквивалентны. По части производительности в mysql - left join выполняется строго в одном порядке. (right join, к слову, mysql делать не умеет, переписывает в left), тогда как для inner планировщик может свободно изменять порядок объединения и использовать другие варианты индексов.
Старомодная запись через from t1, t2 - всё так же inner join. Обе записи планировщик переписывает в идентичное представление.
in (subquery) штука повеселее. В старых версиях была бага и такой запрос был отвратителен по производительности, сейчас подкрутили. Емнип, тоже может быть переписан планировщиком в inner join, а может и так выполняться. По усмотрению планировщика.

Универсально можно сказать только то, что не надо делать left join, если не нужно именно его поведение. В остальных случаях бывают сюрпризы из-за реального распределения данных.

 

Powered by ExBB FM 1.0 RC1