Cat2...Трехзвенку используют те, кто не умеет писать хранимые процедуры и тригеры Оппаньки... Весьма сильное заявление.
А так-то мужики и не знают...
Ну теперь им глазки-то приоткрыли...

Ay-yAlex Kuznetsovпропущено...
Оппаньки... Весьма сильное заявление.
А так-то мужики и не знают...
Ну теперь им глазки-то приоткрыли...
А что используют знающие мужики?А знающие мужики действуют в зависимости от задач проекта и архитектуры решения.
И соответственно в необходимых случаях используют либо клиент/серверную архитектуру, либо N-звенную.

Обычно бизнес логику выносят в "средний" слой в крупных проектах, работа которых не должна зависеть от конкретной реализации того или иного диалекта работы с БД, а будет использовать в основном ANSI SQL, т.е. то, что должно поддерживаться как минимум всеми поставщиками БД. Естественно, что в таком случае происходит отказ от использования хранимых процедур и триггеров, т.к. при переходе на другую БД пришлось-бы переписывать много кода...

Относительно Вашего вопроса:
Отказаться от использования DataAware компонентов. "Собирать" информацию в памяти, затем выполнить "быструю" транзакцию, состоящую из вставки данных в различные таблицы. И зафиксировать её в случае успешности или откатить в случае ошибки... Открывать транзакцию лучше перед работой с таблицами, закрывать/откатывать сразу по завершении.
Можно даже на основе собранной информации сгенерировать SQL скрипт и выполнить его "одним махом".

Ay-yAlex Kuznetsov,
Спасибо.
Где моьно почитать и посмотреть хорошие примеры?Попытайтесь найти книги по архитектуре крупных решений, таких, как например SAP, MS Dynamix AX, 1С 8.2 и т.д.
В общем-то правило одно, транзакция должна быть как можно короче по времени, т.е. открыл транзакцию, тут-же изменил данные и сразу закрыл транзакцию. Дело в том, что в сложных, высоко нагруженных системах, необходимо стремиться к снижению нагрузки на базу данных, соответственно предпочтительней не выносить бизнес логику на уровень БД дабы не нагружать излишне сервер БД неспецифичной для него работой.

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

У меня был поучительный опыт работы с Oracle E-Business Suite, в ходе которой я увидел как не стоит разрабатывать сложные ERP системы. Связано это с тем, что изначально на архитектурном уровне в OEBS позволено размещать бизнес логику как на клиентском уровне, т.е. представление данных(Oracle Forms), так и на среднем уровне, плюс в добавок на уровне БД, в виде тех-же хранимых процедур, функций и триггеров. И вот представьте, что есть бизнес процесс, логика которого "размазана" по всем этим уровням. И нужно его доработать либо изменить. Сответственно нужно проанализировать в каком именно месте нужно будет вносить изменения/дополнения, ну а затем собственно их внести. Теперь представьте, что по какой-то причине оказалось, что часть изменений придётся сделать на уровне представления (ну например добавить какие-то вычисления), а часть на уровне хранимых процедур и триггеров(мало-ли). Соответственно вместо того, чтобы сделать доработку в одном месте (на среднем уровне) придется её делать в трёх разных местах...