Всем привет!

Требуется разбить результат запроса на группы с одинаковым количеством строк и перенумеровать получившиеся группы. Количество строк в группе будет передаваться из вне, в виде параметра. Количество строк, возвращаемое запросом, заранее неизвестно.
Логика разбиения простая - сортируем результат, с первой строки начинаем формировать первую группу, как насобирали N-строк - начинаем формировать следующую группу. Последняя группа может иметь строк меньше, чем переданное N, если результат запрос не делится на целое кол-во групп.

Решил так:


Но подумал - может просмотрел какую-то аналитическую функцию, которая делает тоже самое?
Что-то навроде NTILE, но которая на вход получает не количество групп, а количество строк в группе?

[quot Elic]Начинучка
Данное условие, как и обращение к all_objects - это исключительно для демонстрационных целей требуемого.... Думаю - на 20-ти строках вполне себе показана суть желаемого? Понятное дело, что в реальности запрос будет не из all_tables и условия по ROWNUM в нем не будет. А если бы и было - запрос не ставит цель выбрать N-первых(последних) записей (если вы про то, что сортировка сработает только после отработки этого условия). Всё что требуется - разбить результат запроса на "пакеты" одинаковой ширины в пределах заданного количества.... Сортировка строк в группе, ровно и как групп между собой - в принципе, не важна.

Anatoly BНачинучка,

Речь о другом.
Чем row_number() over(order by created) отличается от rownum в запросе?тем, что запрос будет работать в СУБД, отличной от Oracle. И если поддержка оконно-аналитических функций в ней есть, то вот ROWNUM - отсутствует как класс. Спросил же в оракловой ветке потому, что считаю, что тут наиболее компетентные и авторитетные специалисты в области оконных функций. И мнение это основывается на том, что в оракле эти функции есть с незапамятных времен (с версии 8i). И только ленивый их не использует. В то время как в других СУБД - это сравнительно "недавно" появившееся новшество и многие ещё не совсем в курсе дел.....

MaximaXXL,

СУБД MS SQL 2012 и выше. TOP n не подходит. Решаемая задача - удаление большого числа записей небольшими порциями. TOP n плохо вписывается, так как удалять нужно по определенному условию, которое непокрыто индексами, что приводит к многократным неоптимальным выборкам со сканами этой большой таблицы.
Было решено один раз выбирать список удаляемых ID (первичный ключ с кластерным индексом) во временную таблицу, бить полученную выборку на "пакеты" и удалять данные попакетно. При этом в целевой таблице данные выбираются по ID, что допускает использование кластерного индекса (seek) и увеличивает скорость обработки данных.

MaximaXXL,

Потому что условия выборки не ложатся на существующую схему индексирования.
Соответственно, если делать select top(n) from t where <тут условия вне индексов таблицы>, то возникает fullscan таблицы в которой порядка 500 млн. записей. А так как это все делается в цикле, то получается печалька. И самое грустное - это блокировочный характер скульсервера. Который решает не утруждать себя строчными блокировками и эскалирует блокировку до уровня таблицы, что ставит на колени всё остальное, работающее с этой же таблицей....

Vint,

вопрос был не о том, как это реализовать в другое СУБД. вопрос был о том - нет ли аналитической функции, которая бы заменила собой конструкцию - ceil(row_number() over(order by created)/ 6 )
почему вопрос был задан именно тут - я уже ответил Анатолию Б. Все остальные ответы были исключительно для удовлетворения любопытства MaximaXXL и к первоначальному вопросу отношения не имеют.

По сути вопроса ответ получен - готовой функции нет, используемое решение для деления множества на пакеты - вполне себе оптимальное.

Vint,

голову включи и почитай чего делает предложенный тобой и упомянутый мною выше NTILE - он делит выборку на заданное число групп. А мне не нужно заданное число групп, мне нужно - заданное количество строк в группе. Чтобы прикрутить NTILE именно для своей задачи, мне нужно будет знать количество строк, возвращаемых выборкой, поделить его на число строк в группе, чтобы вычислить кол-во групп, формируемое NTILE. Точно думаешь, что это будет проще того, что есть сейчас?
Уж если пытаешься отвечать, то хотя бы вникай в суть дискуссии. Иначе получается как в рекламе про жвачку - что иногда лучше жевать, чем говорить.....

Vint,

Что ещё раз выдаёт в тебе нечитателя....
Задача была озвучена - с минимальными затратами по ресурсам сервера и с минимальными помехами другим сессиям, удалить некоторое количество данных с большой высоконагруженной таблицы. По сути, выполнять удаление в фоне.
А теперь расскажи мне, как параллельные вычисления позволяют снизить потребляемые ресурсы и ожидания доступа к таблице и журнальному логу в среде блокировочника. При условии, что удаляемые данные равномерно размазаны по страницам и сервер отказывается вешать блокировки уровня строк-страниц, а сразу эскалируется до уровня блокировки таблицы. Буду рад услышать варианты решений от неоленя.

env,

Разбиение на "пакеты" идет по значению ID. ID - первичный ключ с кластерным индексом (для ораклистов - очень приближенный аналог IOT).
Тут суть в том, что остаток от деления будет раскидывать близкие по значению записи в совершенно разные группы. В результате чего, при удалении записей одного "пакета" будет затронуто бОльшее число страниц. При первоначально выбранном алгоритме разбиения вероятность попадания близких по значению ID в один пакет - сильно выше.

Тут только из этих соображений делался выбор. Возможно, то экономия на спичках.