AkinaЛебедкиноднако это не будет работать если понадобится логика типа: (товар-1 И товар-3) ИЛИ товар-2.
Если логика столь многообразна - можно переходить на суммирование условных выражений:
1.
2.
3.
4.
5.
SELECT id2
FROM table
GROUP BY id2
HAVING (SUM(id1 IN (1,3)) = 2)
OR (SUM(id1 IN (2)) = 1)
Подобный подход позволяет легко строить достаточно сложные условия отбора, например:
1.
2.
3.
4.
5.
6.
SUM (id1 IN (1,2,3,4,5)) BETWEEN 2 AND 4 -- от 2 до 4 товаров из 5 заданных
SUM (id1 IN (1,2,3,4,5)) >= 3 -- не менее 3 товаров из 5 заданных
SUM (id1 IN (1,2,3,4,5)) < 3 -- строго менее 3 товаров из 5 заданных
SUM (id1 IN (1,2,3,4,5)) = 0 -- ни одного товара из 5 заданных
SUM (id1 IN (1,2,3,4,5)) = 3 -- строго 3 товара из 5 заданных
SUM (id1 IN (1,2,3,4,5)) = 5 -- строго все товары из 5 заданных
Причём любое количество таких частных условий могут объединяться произвольным способом с использованием логических операций и скобок, а сами суммируемые условия могут включать несколько полей:
1.
SUM((id1 IN (11,12,13)) AND (id2 > id1)) > 1
И получающееся суммарное выражение при этом останется достаточно легко читаемым.
Решение, которое показал MasterZiv, при таких требованиях превратится в сущий кошмар даже чисто синтаксически - не говоря уж о динамическом построении текста запроса. Оно хорошо лишь в достаточно частных случаях при малом количестве отборов - попробуй с его подходом построить запрос для выборки с условием "от 2 до 4 товаров из 5 заданных" или задав полсотни, а не два, товаров, и сразу поймёшь, что я имею в виду.
вы не то оптимизируете, критерий у вас неверный.
вот , чтобы примерно представить, как выглядит мало-мальски громоздкий запрос:
www.sql.ru/forum/1160179/pomogite-optimizirovat-zapros
этот вот запрос
SELECT id2
FROM table
GROUP BY id2
HAVING (SUM(id1 IN (1,3)) = 2)
OR (SUM(id1 IN (2)) = 1)
не оставлять серваку вообще никаких шансов что-то оптимизировать, потому что
всегда обрабатывает все записи.
так писать можно только если у тебя очень маленькая эта таблица и гарантировано не будет расти.
