Роман ДынникВозьмем ORDER/Detail.
Что бы сохранить счет оптимальным способом (одним вызовом):
1) для PL/SQL варианта понадобиться сериализовать объект в xml, вызвать sp на PL/SQL, там "разобрать" xml и сделать соответствующие инсерты в мастер и деталь.
2) для варианта с java вы работаете в терминах объектов и на стороне клиента, и на стороне сервера приложения и на стороне сервера СУБД.
Поэтому если у вас плоский объект, возможно выбор будет в пользу PL/SQL, если же иерархический - то он прямой кандидат для реализации CRUD- операций на java.

Ооопс. А вот для варианта 2 (java) внутри логика разве не будет как и варианте 1 разбирать переданный для расширенной ХП обьект по косточкам и делать соотвествующие инсерты/апдейты в мастер и детайл ? А чем не устраивает стандартно для клиента открыть транзакцию, записать мастер, записать детайл, подтвердить транзакцию ? Ну а если даже уж хочется оптимальным (?) способом, то кто мешает сделать такую ХП:
Теперь клиент спокойно может одним вызовом заносить данные:
Так же при желании на эту процедуру можно сделать веб-сервис и использовать его в HTTP протоколе или SOAP. Плюс можно даже в другой удаленной СУБД ее организовать как удаленную процедуру вызовом через стандартные инет-протоколы:
Как видно и без Java мы прекрасно работаем с XML, веб-сервисами и любыми нужными нам фичами.

Роман ДынникНичего она (Java) не мешается, Oracle-у уж точно :), а что касается Sybase дык писать нужно лучше чтоб под ногами java не мешалась.
Дык мы и стараемся на Sybase писать так, чтобы Java родимая не мешалась, пользуясь только стандартными и неплохими возможностями WatcomSQL, без загрузки сервера кушающей память JVM :)

Роман ДынникМы говорим не про автоматическую/полуавтоматическую сериализацию (в случае .NET) через SOAP или RMI а про передачу объекта в процедуру через "строковый" параметр XML. Вот чтоб в этот строковый параметр значение(объект в виде XML) запихнуть и нужны усилия со стороны разработчика.
Минуточку - так я и привел пример процедуры в СУБД, которая элементарно превращается в SOAP-процедуру, с которой клиентское приложение может работать через тот же 80 порт на получение и передачу данных, вообще не используя никаких ODBC, JDBC, ADO.NET и прочего. А с клиентских приложений по моему все кому не лень могут с XML и веб-сервисами работать.

Роман Дынник автор через тот же 80 порт
работа с сервером ч/з HTTP/S - это еще одна ОЧЕНЬ длинная песня, тут можно и про безопасность тему развить и производительность сравнить и про целесообразность погорорить...

Я еще пример приведу. Допустим для какого то класса у вас глубина наследования равная 5.
Соответственно на сервере, если CRUD в слое хп вам надо выполнить:
т.е. из хп5 вызывается хп4, из хп4 - хп3 и т.д. до 1-го уровня
и в каждой процедуре делать OPENXML. Как вы думаете, с производительностью все нормально будет?
Ну во первых кто мешает вызывать просто sp_Ins5(@xml), передавая туда сразу все аттрибуты класса и его предков ? Во вторых Вы пытаетесь на РСУБД наложить ООП, а при моем подходе это просто ни к чему. Зачем спрашивается на уровне клиента плодить бизнес-классы, если вся бизнес-логика лежит на СУБД и от клиента требуется ума только получить данные в виде набора данных, показать их для просмотра, организовать их отложенное изменение и потом пакетно сохранить все изменения ? Для организации такой работы в любой среде построения клиентов сейчас существуют стандартные компоненты доступа к данным, их визуального просмотра и построения отчетов. Этого вполне достаточно, чтобы организовать клиента в виде GUI приложения или интернет-проекта. В данном случае по моему личному мнению ООП будет использоваться по прямому его назначению - быстрой организации и легкой поддержки интерфейсной части. Всякие попытки перенести бизнес-обьекты на классы и потом танцевать с бубном по проведению их хранения и эффективности обработки на РСУБД только усложняют задачу. В конце концов при автоматизации какой то задачи у нас нигде в постановке нет задания создать аналог реального отображения обьектов. Нам всего то нужно обеспечечить хранение и обработку информации (именно информации, а не обьектов), где лучше всего подходят РСУБД и организовать удобный интерфейс работы с пользователем, где ООП очень полезна в плане создания повторно-наследуемых форм, компонент и других интерфейсных частей приложения. И тут, как только мы данные РСУБД начинаем рассматривать именно как информацию, а не понятно для чего нужные обьекты, все становиться на свои места. Плюс не понятно, что именно должно наследоваться в бизнес-обьектах - если какие то аттрибуты и логику сущностей можно выделить единым целым, то на "Один-ко-Многим" это все прекрасно реализуется по таблицам, триггерам, представлениям и хранимым процедурам по нормальным формам. Так что лично для меня понятия "Сущности-Аттрибуты" гораздо лучше ложаться на ТЗ поставленных задач, чем "Классы-Обьекты-Свойства". Единственный существенный недостаток, присущий кстати как РСУБД, так и ООП - это строгая формализация данных, где в обоих случаях поддержка обьектов с неизвестным заранее кол-вом аттрибутов будет стоить дополнительных усилий в проектировании и реализации эффективной работы. Опять же мое личное мнение - для этого необходимо вообще разделять данные и код бизнес-логики, причем данные должны быть структурами с произвольным набором аттрибутов определенных в словаре доменов, а бизнес-логика оперировать такими структурами с подходящими по наличию доменов и их значений (где опять же создаются расширяемые словари глаголов по принципам работы функциональных языков) и связывающим звеном для манипуляции множествами является язык запросов. В данном случае очень похоже на продвижение формата XML, хотя куда он двинется и что из этого получится пока не понятно :)