iscrafmесли ты не понял выпендриваешься здесь ты,
Ты мне ещё расскажи, что я ел на завтрак.

iscrafmа я просто показываю насколько ты дебил.
Кому? Ты так и не ответил на этот вопрос.

iscrafmЭто и ответ на второй вопрос.
Ну прости, что наступил на мозоль. Я думал, за столько лет ты научился спокойно к этому относиться.

AmberitPIPELINED - это один подход; Возврат коллекции, созданной как SQL-тип в БД и в которую в результате обработки помещены данные - это другой подход;
Я как раз об этом. Такой взгляд производит впечатление жутко поверхностного, на уровне "читал, что такое есть".

Между этими подходами различия примерно как между хранимой процедурой и хранимой процедурой, работающей в автономной транзакции. Просто дополнительная фича (pipelined / autonomous_transaction) подключает некоторую особую механику сервера. Вы же не называете эти два варианта принципиально разными типами процедур, верно? И когда виртуальный экзаменатор спросит "какие есть типы ХП в Oracle", Вы же не скажете "есть процедуры, есть функции, а есть работающие в автономных транзакциях"?

AmberitПодход с REF CURSOR RETURN не используем, вместо него используются либо PIPELINED, либо коллекции.
Меня удивляет эта фраза. Объясню, почему. Использовать ли строгую типизацию либо нет - решение, относящееся скорее к стандартам кодирования, чем к архитектурным вопросам. В принципе, можно принять решение и изменить все типизированные курсоры на нетипизированные (или наоборот, 95% нетипизированных курсоров на типизированные), и это ничуть, совсем не изменит функционирования приложения. В то же время возврат курсора и возврат коллекции - совсем разные вещи как с точки зрения функционирования сервера, так и с точки зрения изобразительных возможностей кода. Многие задачи тривиально решаются в одном из этих подходов и сравнительно сложно - в другом. Соответственно, выбирать тот или иной подход в зависимости от того, хотим ли мы в данном месте типизированность - сомнительное решение.

AmberitsoftwarerСоответственно, там, где есть такой стандарт, практически всегда выбирается что-то одно, как минимум в рамках приложения.
Полностью с Вами согласен. Но кто сказал, что разработчик БД поддерживает только 1 приложение?
Не обязательно одно. Но если есть данный в ощущениях зоопарк, в нём будут и ХП-онли, и "запросные", и всякие другие приложения. Если же поддерживается, например, спектр приложений команды, созданных по постепенно прогрессирующим, но изначально наличествующим правилам кодирования, то большой разницы я бы не ожидал. Очень сомнительно, что в двухтысячном коду сделали систему на рефкурсорах, а в две тысячи втором вдруг решили всё подряд писать на табличных функциях. Ваша же фраза, о которой идёт речь, звучала так, словно буквально для каждой функции выбирается, какой интерфейс с клиентом у неё будет.

AmberitСтандарт принять может быть и проще, а вот менять существующий, успешно и надежно работающий и приносящий прибыль код ради "чистоты стандартов" - слегка неверно, я считаю.
Я бы понял этот аргумент, если бы рефкурсоры были существенно более новым механизмом. Но поскольку они появились раньше, и при этом до сих пор остаются основным, более удобным для большинства задач средством - необходимости "менять стандарт" не видно. Я бы ожидал, что изначально приняли стандарт использования рефкурсоров, а когда появилась возможность/потребность иногда использовать табличные функции - либо доработали компоненты доступа, чтобы уметь работать и с ними тоже, либо приняли стандарт "при необходимости делается табличная и возвращается клиенту обёрнутой в рефкурсор".

Ну а вообще - это большая тема. Менять ради чистоты стандартов - согласен, неверно. Давать коду устаревать и доходить до состояния дерьма мамонта - тоже неверно. Так что если рассчитываем на долгую жизнь приложения, истина где-то посередине.

iscrafmя в сортах дерьма не разбираюсь

С уважением,
дегенарат
Попробуй разобраться. Для тебя это будет большим шагом вперёд.

iscrafmsoftwarerПопробуй разобраться. Для тебя это будет большим шагом вперёд.
Ты "непрерывный тормоз" по твоей же классификации?

С уважением,
дегенерат
Этот вопрос к заинтересовавшим тебя сортам дерьма отношения не имеет.

iscrafmsoftwarerЭтот вопрос к заинтересовавшим тебя сортам дерьма отношения не имеет.
По-русски же сказано:
iscrafmя в сортах дерьма не разбираюсь
С уважением,
дегенерат
Ты ни в чём не разбираешься, но кое-чем таки интересуешься. Или снова начнёшь рассказывать, что это одно и то же, как view и запросы?

iscrafmт.е. они меня не интересуют.
О, угадал.

Надо сказать, что за единственный топик ты почти полностью исчерпал свой потенциал клоуна. Жаль.

iscrafmНужно ссылку на эту тему на сайтах где ты публикуешь свои "творения" дать, хорошо показывает наигранную подноготную
И этот человек уверен, что он говорит по-русски Давай, кто ж мешает-то?

iscrafmзапрос - это текст, в начале темы под ним понимали сам View.
Кто понимал? Называй поимённо.

iscrafmдо сих пор ожидается
Кем ожидается?

iscrafmа также View с параметрами
Погуглить по заданным словам так и не попробуешь? Ну тогда ожидай и дальше.