Dmitry EliseevНеважно в текстовый лог идёт запись или в лог со специфическим форматом. На основной вопрос так и нет ответа. Как сделать логирование БИЗНЕС процесса, когда этот процесс меняет содержимое нескольких таблиц (от трёх до десяти). Куда вешать триггер?Хотите самостоятельно логировать изменения в каждой отдельной таблице? Тогда на каждую из логируемых таблиц создаете триггер и "парную" ей таблицу для логирования изменений. Разворачивание таблиц-логов для "разбора полетов" - отдельная, достаточно "веселая" задача...
Dmitry Eliseevrockclimberпропущено...
1 SQL-запрос и три таблицы. И, между прочим, на первой странице топика все это уже описано.
Там описано для случая, когда пользователями/правами/ролями управляют на уровне приложения. Мне интересно как это сделать на уровне СУБД.Принцип тот же самый. Только в одном случае это нужно делать "ручками", а в другом случае - фича базы данных.
Например, в Oracle это что-то типа "fine-grained access control" или "virtual private database". В общих чертах там это работает как прозрачное (и невидимое) для пользователя включение дополнительного условия фильтрации (с учетом пользователя и его ограничений) в любую DML-команду.
Dmitry EliseevКстати, использование хранимых процедур ничем не отличается от написание того же кода в приложении. Т.е. фактически только место исполнения кода разное. В пользу кода в приложении говорит переносимость между СУБД.Переносимость между разными СУБД актуальна только когда стоимость переноса равна нулю - а такого не бывает даже при переезде между разными "бесплатными" СУБД.

Dmitry EliseevПеренос между разными SQL-ными СУБД вполне возможен и по экономическим причинам. Например с Oracle, на PostgresQL, чтобы продать решение без навязывания покупки Оракла, или исходя из удобства/неудобства использования диалекта SQL.Приводить "экономические причины" не серьезно - аргумент "для очень бедных". В действительно серьезных проектах стоимость лицензий никогда не составляет сколь-либо значимую долю расходов. Получается, типа, "мы тут замутили проЭкт на 100500 мульенов денег, но купить лицензионный софт нам капусты не хватает"...
И не забываем, что ни один "бесплатный продукт" никогда не был бесплатным в обслуживании - вплоть до того, что обслуживание (иногда) обходится гораздо дороже, чем для "платных"...

Ну, а "удобство/неудобство диалекта SQL" - вообще смешно...
Dmitry EliseevВесьма распространена ситуация когда у заказчика используется Oracle , разработчику удобнее использовать Postgres , а тесты гоняются на H2 . При этом liquibase обеспечивает единство баз под всеми этими платформами.Вы лучше расскажите (потенциальным заказчикам), ГДЕ практикуется подход разработки с ТАКИМ "зоопарком" - сугубо "во избежание"...

Заодно попытайтесь озвучить аргументы, по которым разработку (в частности, под Oracle) нужно (и возможно) использовать совершенно "перпендикулярные" средства...

Очень надеюсь, что Вы (хотя бы теоретически) подозреваете, что при "зоопарк-подходе" Вы НИКОГДА не сможете использовать сколь-нибудь значимую часть реальных возможностей целевой платформы заказчика. Для SQL-серверов это (в лучшем случае) будет ограничено "базовыми" SQL-командами (select/insert/update/delete) c крайне упрощенным синтаксисом.

Dmitry Eliseevсмешно, когда у СУБД нет автоинкрементных полей и типа TIME, так смешно, что плакать хочется...И это - все претензии?! Ну, что тут сказать... Поплачьте...

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

И мне ОЧЕНЬ хочется посмотреть, как Вы свой проект, который вели на платформе, где есть и автоинкреммент, и TIME перенесете туда, где "в-лоб" такого не наблюдается физически... Особенно - если Вы на них "насмерть" завязаны...