Получается, что самсунг стоит 140 евро в 2020 году и 150 в 2021 году.
Мне надо получить данные из второй таблицы там, где цены товаров когда-то были равны четко заданным значениям. Например, я хочу получить товары, которые стоили когда-то 140 долларов и 150 евро, тогда у меня должен быть выведен только самсунг. Если я хочу получить товары, которые стоили когда-то 200 и 205 евро, то мне должно вывести только нокию (так как LG никогда не стоит 200 долларов, то он не должен быть выведен).
Подскажите, пожалуйста, как построить SQL запрос в таком формате.
SELECT *
FROM goods
WHERE EXISTS ( SELECT NULL
FROM prices
WHERE goods.id = prices.id_goods
AND prices.price = 200 )
AND EXISTS ( SELECT NULL
FROM prices
WHERE goods.id = prices.id_goods
AND prices.price = 205 )
Чем больше цен на один товар (записей в таблице), тем выше вероятность, что такой запрос будет производительнее решения от Slava Rozhnev. Соответственно, чем больше цен задано, тем оно менее вероятно.
При условии, что имеются оптимальные индексы, конечно.
Akina, блин точно
Сам же использовал неделю назад это свойство exists на работе.
а здесь вылетело из головы.
я бы это написал в виде ответа, а не комментария - готовый код, как-никак
Но, главное, он не будет давать дубли, если на один и тот же товар есть пара одинаковых цен, как мой джойн
select g.id, g.name, count(distinct price)
from goods g
join prices p on g.id = p.id_goods
where price in (200, 205) -- prices that we need to search
group by g.id, g.name
having count(distinct price) = 2; -- 2 count different prices
это конечно вариант, но мне не нравится этот костыль с group by g.name, только для того чтобы ошибку подавить
ну и файлсорт тут будет изо всех щелей торчать
Индексы тебе не помогут.
Запрос будет собирать во временную таблицу все строки с ценой 150 и 140, а это десятки тысяч.
И только после этого по этой временной таблице отфильтровывать такие, которые встречаются оба раза
А вот эксплейн нормального запроса
+====+=============+=======+=========+=========+================+======+==========================+
| id | select_type | table | key | key_len | ref | rows | Extra |
+====+=============+=======+=========+=========+================+======+==========================+
| 1 | SIMPLE | p1 | price | 5 | const | 1 | Using where; Using index |
+----+-------------+-------+---------+---------+----------------+------+--------------------------+
| 1 | SIMPLE | p2 | price | 10 | const,id_goods | 1 | Using index |
+----+-------------+-------+---------+---------+----------------+------+--------------------------+
| 1 | SIMPLE | g | PRIMARY | 4 | id_goods | 1 | |
+----+-------------+-------+---------+---------+----------------+------+--------------------------+
Даниил Горбенко, Насколько часто нужен такой запрос? Если да, то при таких объемах данных можно смотреть в сторону специализированных для аналитики баз данных. Например Druid
Летят Холмс с Ватсоном на воздушном шаре. И спят в полете. Просыпаются
над какой-то незнакомой землей, видят - внизу какой-то хрен коров пасет.
Снизились они и спрашивают мужика:
- Скажите, сэр, где мы находимся?
- На воздушном шаре.
- Спасибо, сэр! - и летят вверх. Холмс задумчиво говорит:
- Интересная местность, Ватсон! Программист пасет коров!
- Холмс, а с чего вы взяли, что он программист?
- Это элементарно! Во-первых, он долго думал над ответом. Во-вторых, его
ответ был абсолютно точен. И в третьих - абсолютно бесполезен!
Простой
