Философия тут простая - ВСЕ данные, которые участвуют в запросе, должны присутствовать в базе данных.
А это значит, либо данные заливать перед самим запросом во временную таблицу (что имеет смысл делать только при очень большой нужде, например большой объем данных и мало оперативной памяти на бакэнде) либо, все данные уже есть в базе, и выбирать их по идентификатору, добавляя их список в
where id in (1,2,3,...)
Так же есть неплохой по моему мнению (но считается говнокодом) подход - когда данные это сам запрос, что то типа указывая данные для фильтрации по одному
select ... where name like '%sdf%' union
select .. where name like '%zxcvx%' union ...
или подготовив вложенную виртуальную таблицу с данными
select ... from (
select 1,2,3 from dual union
select 5,6,7 from dual union ...
) x where ...
p.s. времена нынче не нищие, оперативной памяти много (осознайте, что гигабайт это миллионы или даже сотни миллионов строк), очень часто значительно проще, дешевле, быстрее... выгрузить данные, с которыми нужно работать в оперативную память бакэнда целиком (и хранить их там), обработать классическими методами, и залить результат в базу
Понятно этот подход нужно использовать с умом и не вставлять в любое место бездумно.
Реляционная база данных - это компромис, когда ты платишь сложностью работы с данными, кучей ограничений и низкой скоростью, за универсальность, легкий многопользовательский доступ и автоматический контроль за целостностью (транзакции), и вот когда этим можно пренебречь, появляется возможность делать так как описал
Средний
