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

У меня складывается ощущение, что мы сейчас как два слепых мудреца: ощупываем вроде одного слона, но имеем слегка разные мнения... :-)

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

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

softwarerВ принципе, можно принять решение и изменить все типизированные курсоры на нетипизированные (или наоборот, 95% нетипизированных курсоров на типизированные), и это ничуть, совсем не изменит функционирования приложения.

Сложно говорить об "абстрактном приложении в вакууме", поэтому скажу о тех приложениях, в которых я имею честь оставлять свои следы сегодня: после подобного изменения жизненный цикл приложений поменяется достаточно сильно. Поэтому просто так подобные изменения делаться не будут.

softwarerСоответственно, выбирать тот или иной подход в зависимости от того, хотим ли мы в данном месте типизированность - сомнительное решение.
Любой подход нужно применять ко времени и к месту. Хотел бы обратить внимание, что выбранный подход достаточно часто является консенсусом между подходами, используемыми разработчиками БД и подходами, используемыми разработчиками приложений. Согласитесь, что подходы будут иметь различия, например для PHP и JAVA EE функционала. Конечно, можно свести все к одному подходу, но зачем? Кодировать в рамках стандарта исключительно ради стандарта?

softwarerВаша же фраза, о которой идёт речь, звучала так, словно буквально для каждой функции выбирается, какой интерфейс с клиентом у неё будет.
Значит, я недостаточно ясно выразил свои мысли, и это нужно читать так: "Для функций каждого приложения используется тот интерфейс, который является стандартом конкретно этого приложения".

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

vadiminfo,
Сохранится. Данные операции доведены до автоматизма кодирования. И выбор в этом случае сводится только к выбору типа блокировки (оптимистическая, пессимистическая). Причем в любом случае для разработчиков приложений от этого выбора практически ничего не изменяется, и они по-прежнему остаются изолированными от структуры БД.

Ваше незнание того, как оптимально организовать оптимистическую блокировку, не значит, что ее нельзя организовать...

С оговоркой: если используются ХП