Есть наверное достаточно типичная задача по работе с интервалами.
Есть оплаченные пользователями подписки (подписки разной длительности и стоимости).
Есть аварии, при которых услуги не предоставлялись, и необходимо посчитать компенсацию.
В общем виде нужные мне данные я получаю таким образом (P - подписки, R - аварии):


RR1R2RLPVP1P2PLLLL1L2KF1162373100182244182211001162374100123018716230,38938116237510013196316190,550116237610019256419230,66766116237810016204416201100116237910020244320230,7575216,116,20,141001230180,116,116,20,0060216,116,20,15100131960,116,116,20,0171216,116,20,18100162040,116,116,20,025211008146210024273710012164
Визуальное представление этого запроса нарисовано в аттаче.
Версия Oracle 10g.

В реальной задаче некоторые моменты усложняют ее решение.
Во-первых, подписки приходится получать достаточно "тяжелым" запросом, не всегда покрываемым индексами. Хотя результат запроса как правило небольшой, десятки (в худшем случае тысячи) записей.
Во-вторых, компенсация — это перечень определенных действий. Можно выполнять эти действия в цикле (с использованием курсора). Но мне кажется, что эффективнее использовать update/merge с определенными группами подписок (критерии которых будут добавляться в where). Но тогда нужно будет выполнять "тяжелые" запросы несколько раз, для каждой группы.

Было бы удобно сохранить полученный набор данных во временную коллекцию и в дальнейшем использовать ее в SQL-запросах (добавляя join и where).
Можно использовать временные таблицы, но их нужно определять (создавать) в базе данных, а я бы не хотел фиксировать структуру этой таблицы (вдруг потребуется добавить или изменить столбцы).
В PL/SQL есть коллекции, но использовать их в SQL-запросах как-то очень сложно.
Не подскажите альтернативы? Или пример использования коллекций в запросах.

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

Может я неправильно понял?

Нагуглил « Managing Automatic System Tasks Using the Maintenance Window ». И как я понял из текста, речь о том, как автоматизировать запуск подобных регулярных задач. Но я такой запуск и со стороны клиента могу обеспечить.
Я имел ввиду то, что если я в этой временной таблице удалю или переименую какой-нибудь столбец, то ранее написанный скрипт, работающий с этой таблицей, перестанет работать.
То есть если у меня есть уже работающий скрипт версии 1, использующий временную таблицу tmp_queue, а я хочу этот скрипт доработать до версии 2 (и чтобы при этом скрипт версии 1 продолжал работать, пока я не завершу версию 2 и не замещу ею версию 1), то в версии 2 мне нельзя изменять эту временную таблицу tmp_queue, необходимо сделать ее копию tmp_queue_v2 и использовать именно ее.

Идею понял.
Видимо так и придется сделать.
Но все же табличные переменные удобнее. Я надеялся, что коллекции PL/SQL можно использовать в этой роли.

Она ведь будет вызываться (и выполнять сложную выборку данных) при каждом обращении.
А я как раз и хочу это предотвратить тем, чтобы один раз сохранить результаты сложного запроса в каком-то буфере (табличной переменной или временной таблице) и в последующих SQL-запросах использовать этот буфер.

Так объем данных небольшой. Обычно менее сотни строк. В худшем случае будет менее 20 тысяч строк.