Не спасла бы.
Применение и этой кляузы требует знание о структуре результата на этапе проектирования а не на этапе исполнения. Если мы на этапе проектирования не знаем структуру результата,  запрос все равно придется формировать динамически. Ну разве троху компактнее получается текст. В общем и целом pivot и unpivot это просто попсовая плюшка, не очень чтоб уж прям и мастхав.


И ведь ЧСХ ни одного коментария к статье, что тема заявленной над катом динамики pivot не раскрыта чуть менее чем полностью в виду ее отсутствия.

mbasil, из вашего примера я не понял, вы ГТТ создаете одну на все случаи жизни? Если так, от чего так мало столбцов? Пивотинг over 99 значений по 4 символа в каждом столбце, полагаете вам с лихвой хватит?

Это сообщение отредактировал(а) Zloxa - 19.1.2016, 02:09

Да, на все случаи жизни и для всех пользователей (GLOBAL TEMPORARY TABLE). Я просто отлаживал текст на маленьком примере, приведеном автором. В Oracle заявлено, что можно создавать таблицы с 1000 столбцами. Правда я задействовал временную таблицу, которая на самом деле "не настоящая" и сколько там можно создавать столбцов не знаю - выяснять лень. 

Некоторык комментарии:
1. Использовал я временную таблицу потому, что для выполнения операции в оперативной памяти при большом объеме может потребоваться слишком много памяти. Конечно, это требует времени на вставки, но DML операции в такой таблице не журналируются и в сегиенты отката не пишутся, так что вместо TRUNCATE можно смело использовать DELETE.
2. Поскольку это матричный отчет, трудно представить себе начальника с красным карандашом в руках и огнем в глазах анализируещего таблицу из 1000 столбцов - "замучается он". Так что по длительноиу размышлению в тртий раз намекаю, что отчеты форматировать надо на клиенте, передавая реляционные данные по сети компактно. Последние тенденции убеждают, что разделение труда между узлами системы не пустой звук, так как объемы сохраняемых данных растут и "напрягать" сервер задачами, которые ему не присущи фцнкционально, по меньшей мере, опрометчиво, даже если у вас супер серевер. Oracle же, например, в 9 версии предлагал форматировать HTML на сервере (ха). А с другой стороны Oacle Reports (хоть и кривоват), но позволяет уже много лет ваять из запросов многостраничные матричные отчеты "супер пупер" сложности.

Это сообщение отредактировал(а) mbasil - 2.2.2013, 08:21

Вы вот опубликовали некое решение. А от какой задачи это решение, наверное забыли упомянуть?
И уж простите за прямоту, но ваши портянки кода - откровенный г0внокод. Я честно попытался их почитать, но так и не понял от какой задачи зто решение.

Задача транспонирования решатеся одним запросом.
В приведенно вами же статье есть ссыль на решение от Кайта для версий <11
В процессе выполнения запросов, при необходимости, используется временный сегмент, совершенно не понятно какие расходы памяти вас так тревожат.


Это сообщение отредактировал(а) Zloxa - 2.2.2013, 12:41

to Zloxa

1. Код пишу, какой умею, во всяком случае он работает. Ясно, что я не пытаюсь предствить данное решение идеальным, как возможно не идеален и запрос, который не влезает в 32К. 
2. Вы читаете только то, что  можете критиковать хамским образом?  То что матричные отчеты надо форматировать на клиенте, а не гонять по сети ненужную метаинформацию, и то что такие инструменты как Oracle Reports это делают автоматически, вы пропустили, видмо, случайно.
3. Второй раз захожу на это ветку и второй же раз получаю от вас мягко говоря неприятные замечания. Видимо вам мои сообщения,  как завсегдатаю не нравятся вообще, а не по сути, а посему позвольте откланяться - вы ведь здесь хозяин

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

А резкая критика гoвнорешений, с моей точки зрения, на публичных ресурсах крайне необходима. И необходима она не столько для тех кто их публикует или тех, кто эту резкую критику преподносит, а для тех, кто молча почитывает и мотает на ус, возможно, сам еще будучи не в состоянии адекватно оценить суть решения.

Это сообщение отредактировал(а) Zloxa - 2.2.2013, 21:11

Не удержусь, чтобы не ответить, хотя и не собирался, поскольку гсп.Zloxa опять вместо рассмотрения сути закопался в формалистику. Отвечаю не ему (так как в похвалах и порицаниях не нуждаюсь), а тем, кто хочет все-же разобраться в предложенной задаче. Есть три способа решения поставленной проблемы:

1. Выполнить "pivoting" в оперативной памяти.
2. Выполнить "pivoting" во временной таблице, примерно так, как я писал в "гОвнОкоде".
3. Выполнить форматирование отчета на клиенте.

Вариант 3 предпочтительный, так как это правильное создание матричного отчета, когда клиенту по сети отправляется меньше информации, чем при "pivoting" в оперативной памяти и сервер не занят второстепенной для него задачей.

Вариант 2 предлагается использовать, когда клиент хочет не только запросить несколько раз результаты "pivoting'а", вырезая, например, отдельные части, но и внести изменения во временную таблицу (по желанию) прежде чем напечатать окончательный отчет.

Выполнять "pivoting" в оперативной памяти по варианту 1 стоит только лишь от лени.

Что касается "гОвнОкода" то связан он отчасти с необходимостью обработки строк, которую трудно сделать "красивой". Кроме того, я и не пытался наводить красоту, возможно именно от лени. Я уже 30 лет пишу коды и, видимо обленился вконец до "гОвнОкода". Полагаю, тем не менее, что вариант 2 вследствие перечисленных выше причин также имеет право на существование. И, ежели кто-либо предпочитающий красоту в коде предложит красивое решение, полагаю все будут только рады. Говорить же, что вариант 2 не нужен никогда потому, что "гОвнОкод" - по меньшей мере, высокомерно.

Это сообщение отредактировал(а) mbasil - 7.2.2013, 15:59

Объясните пожалуйста что вы называете пивотингом в оперативной памяти.

Традиционное решение задачи - динамическое формирование запроса, о котором идет речь в этой теме, и по той ссылке, которая приведена вами же, не есть суть "выполнение пивотинга в оперативной памяти". Выполнение этого запроса сервером не является "выполнением пивотинга в оперативной памяти". Наличие третьего пункта в вашем списке, как бы предполагает что речь идет не об оперативной памяти клиента. Применение своего оригинального подхода в пику ранее озвученных - традиционных вы обосновываете экономией памяти. Какой памяти? Альтернативой какому подходу вы предлагаете свое решение? В этой теме не было озвучено подхода, недостаток которого вы устранили своим решением.

Это сообщение отредактировал(а) Zloxa - 7.2.2013, 20:45

Думаю надо пояснить некоторые моменты:
1. Тема давно имеет только академический интерес. Тот прототип который тогда разрабатывался уже давно почил в бозе.
2. Табличное представление формируется на клиенте, а не на сервере потому что на тот момент вся логика была на сервере.
3. 200-300 столбцов человеку вполне можно обозреть. Смысл как раз и был в том, чтобы наглядно видеть где что.

Если имеет хотя бы академический интерес  , с 11й версии dbms_sql умеет возвращать и refcursor.
Раньше, походу, действительно не умел.
Удивился, что мне было позволено вернуть 1.5к, 5к столбцов, оказывается 1к столбцов это лимит для таблиц, сколько для вьюх-запросов надо буйт пошукать.
Пригорюнился над текстом ошибки, когда попросил 50к столбцов



Это сообщение отредактировал(а) Zloxa - 8.2.2013, 14:58

Ура! Вот теперь

ответа действительно прозвучала 

Кстати, поможет, но лишь отчасти. Конкатенировать три строки уже не получится, но две - да.
Давешняя бага/особенность и по сей день смущает умы постигающие основы эксперементальным способом, а не аналитическим. В продуктивное решение нести такое конечно не след, но де факто получается ограничение длины натив динамик запроса в 64к, а не в 32к

а ручки то - вот они ©   

Это сообщение отредактировал(а) Zloxa - 8.2.2013, 17:36