Гулин Федор,

Когда-то у Oracle , был единственный алгоритм группировки:
- "сначала отсортировать, затем, пробегая по сортированному набору, границы групп определять сравнением текущих полей группировки с ними же в предыдущей записи"

Ясно что такой алгоритм, пока он единственный, всегда, гарантированно и автоматически будет выдавать сортированный по
полям группировки набор данных.
И многие на это сознательно закладывались - зачем дописывать самому Order by, если он автоматически сам окажется такой, какой надо.
Между тем - такое "мнение" - простая логическая ошибка, положившаяся на особенность конкретной реализации алгоритма группировки. Который, в общем случае, не обязан никак быть завязан на предварительную сортировку данных.

На больших наборах данных, этот первоначальный алгоритм работает достаточно плохо, поскольку требует колоссальные объемы работы на предварительную сортировку.

В какой-то момент Oracle реализовал второй алгоритм, существенно (ну, очень-очень существенно) более быстрый на больших наборах -
предварительная сортировка не производится, а по мере пробега по набору строится хеш-таблица, идентифицирующая производимые группы, кодами которой метятся просматриваемые группы.
Такой вариант не только не требует предварительной сортировки, но и замечательно распараллеливается.
В зависимости от размера набора и характеристик группировки, стал применяться тот или иной алгоритм на выбор системы.
Естественно, те, кто поленился дописывать order By стали вопить "как же так! Где же автоматическая сортировка? Это всегда работало!"
Между тем, они были всего лишь жертвами своей собственной логической ошибки и лени рук и мозга.

Если ты не управляешь системой внятно, она управится сама с тем, что считает своими данными, раз тебе от них ничего не надо.
В системах с декларативных описанием алгоритмов пропуск запятых в "казнить нельзя помиловать" - катастрофическая ошибка, означающая неопределенное поведение.

В последних версиях (вроде с 19й, может с 20й) появились макрофункции, которые можно приспособить для решения
вашей "проблемы".
Во всех предыдущих, один из правильных вариантов решения вашей проблемы может быть таким:
Над тремя своими View образуете четвертую, такого содержания



И на клиенте всегда обращаетесь только к ней, с запросом такого вида




Другие варианты, так или иначе, основаны на получение набора данных (курсора) от интерфейсной хранимой процедуры.

Ровно там, где собрался на клиенте опираться на order by во view.
Впрочем, забудь про группировку...

ммм... Ок. Более точное описание будет таким:
Агрегация строилась на очереди агрегатов, реализованной в виде пирамиды, строящейся на поступающем наборе входных данных.
В связи с этим, термин "предварительная сортировка", действительно неверен.
Правильнее сказать так: группировка строилась поверх алгоритма сортировки, расходы на которую были неотделимы от алгоритма группировки,
и цена которой определялась количеством образуемых групп.
Этот вариант и сейчас используется. На малых наборах данных или на наборах с малым числом групп, его производительность близка к идеалу.
В этом смысле, для больших наборов с бедным числом групп, еще надо "посмотреть" - не произошло ли малой деградации с внедрением нового алгоритма.

Точность описания конкретного алгоритма в данную секунду не имеет значения.

Речь, по существу, идет о формировании общей системы ожиданий.
Вот нельзя было в SQL Server - и это очень хорошо .
А Oracle показывает, что работает и ничего не ломает в моих экспериментах.
Ага, давай вот немедленно и воспользуемся наблюдённым...

Stax,

есть существенная разница между "запретить никак" и "гарантии есть".
Из одного не следует другое никак .

Stax,

Когда говорят "порядок гарантируется", подразумевают, что в абстрактных вопросах он гарантируется формальной математикой,
а во всех остальных случаях - юридическим законом или честным словом, записанным на бумаге.

дадите ссылку, где в данном случае почитать о записанных выданных гарантиях?