АнатоЛойЯ не говорил, что требование нужно реализовывать самому, это требование может предъявляться к системе. С помощью каких технологий и инструментов система её закрывает - это уже реализация.мы и говорим о реализации. Конкретно, о реализации логирования вызовов оператора SELECT посредством хранимых процедур, помните? В какую конкретно систему такие возможности встроены, чтобы их не надо было реализовывать самому, не подскажете?
АнатоЛойА слабо под "существующим профайлером" пару сотен пользователей запустить, чтобы понять, какая редиска в 3 часа ночи сервак нагрузила?тот факт, что таблица лога в данном случае сто пудов станет узким местом не учитываем, да? сколько раз пара сотен пользователей обновит у себя оперативное представление? и каждый раз мы это будем логировать? сумасшествие какое то.

tru55iscrafmtru55включают на достаточно короткое время в случае появления каких-то подозрений
подозрение на счет того, смотрел ли человек на экран или нет?

Не на экран, а на данные...и зачем это надо знать? хоть кто-нить может вразумительно ответить, а не на уровне общих рассуждений

tru55Информация бывает открытая и закрытая (по крайней мере, для части публики).
Способы скрыть инфу от "ненужных" глаз бывают разные, в том числе и аудит (в смысле логирования)...вы издеваетесь? как логирование может чего-то скрыть? логирование фиксирует факт совершения операции.

tru55mir_unregistered
Вы точно издеваетесь. К вашему сведению, есть такая вещь как раздача прав доступа, в т.ч. на просмотр данных. Если не хотят, чтобы человек видел какие-то поля, ему их запрещают видеть.
Да ну? А на кой тогда имеется возможность следить за изменениями данных, если их изменяют только те, кто имеет право?вы правда не понимаете, зачем следят за обновлениями данных? Потому что даже те, кто имеет право на обновление, могут внести некорректные данные. Как эта ситуация отображается на логирование выборок?
tru55Я уже упомянул о том, что в Oracle реализована возможность следить за селектами. следить или логировать? разница ощутимая

tru55Если данные изменены ошибочно, то причем тут логирование (если опять же, не брать в расчет "разбор полетов")? логируют как раз для разбора полётов, это же очевидно.

tru55egorych
tru55Я уже упомянул о том, что в Oracle реализована возможность следить за селектами. следить или логировать? разница ощутимая
Под следить я имел ввиду логировать, ибо следить - это в настоящем времени, а логирование позволяет разбираться и в прошедшем.чего можно разобрать, если мы знаем, что пользователь Х 197 раз в день обновил у себя в клиентской программе грид с данными? зачем нужны эти сведения? что полезного мы можем из них почерпнуть? и стоит ли ради их получения увеличивать время разработки и просаживать производительность? - вот вопросы, ответы на которые хочется получить, а не общие рассуждения, что "мол, надо" и "мол, сделано".

tru55Например когда-то имел дело с системой (разрабатывал в том числе), в которой на критические таблицы были навешаны триггера, переносившие при UPDATE/DELETE предыдущую версию данных в исторические таблицы. Эти записи использовались как для разбора полетов, так и для упрощения восстановления предыдущего состояния. это одно и то же )) решение о восстановлении предыдущего состояния принимается по результатам разбора ))
tru55К слову сказать, в Oracle 11 реализована похожая вещь на системном уровне. плюс Ораклу за это.
Но этот вопрос не так интересен, потому что понятен смысл такого логирования. Он имеет право на жизнь и достаточно востребован, чтобы его реализовывать, как с использованием системных средств, так и самодельно

tru551. здесь рассматривается достаточно узкий случай. Как правило, к базе можно доступиться не только через разработанную клиентскую программу, но и другими инструментами
2. для чего - я уже сказал выше - доп. уровень защитынормальная система разграничения доступа решает эти проблемы значительно проще и на мой вкус, правильней воспользоваться ей, чем городить свой велосипед.

3. по поводу производительности:
>> - поскольку это логирование включается периодически, то влияние не столь велико
- вот с какого, интересно? если логирование производится в момент, когда возникли подозрения, то проще смотреть permissions пользователя/группы пользователей, чем запускать логирование, неизвестно, как долго придётся ждать, когда в следующий раз будет вызвана хранимая процедура именно тем пользователем, которому вызывать её не положено, и остальные будут испытывать неудобства всё это время совершенно незаслуженно. Потом, если уж человек добрался до базы через другой инструмент, то уж наверное он сообразит сделать SELECT напрямую, не используя хранимую процедуру, то есть этот инструмент защиты будет обойдён. Так в чём же смысл, я вас спрашиваю?

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

>> - за любой сервис надо платить. Скажем, в Oracle с 10 версии по умолчанию работает
>> постоянный сбор статистики работы, что можно использовать для мониторинга
>> производительности базы, отлова "тяжелого" SQL и проч. Естественно, это доп. нагрузка на
>> сервер. Поэтому, если производительность критична, то эту систему отключают, теряя при этом
>> помянутые удобства
- не видите здесь противоречия? чтобы отловить тяжёлый SQL мы добавляем в систему средство, которое заведомо утяжелит всю систему?

tru554. "сделано" - это не общие рассуждения. Если люди реализовывали это на уровне СУБД (Oracle), значит подобная вещь имеет спросзнаете зачем? чтобы поменьше было велосипедов.
Моё имхо в том, что подобное средство встроено в СУБД скорее для наладки производительности в помощь DBA, а не для реализации мифических дополнительных уровней защиты.
Ну и маркетинговый ход, само собой: "вона чего мы умеем, ни у кого такого нет!" В этом смысле Oracle не сильно отличается от Microsoft.

tru55egorych
чего можно разобрать, если мы знаем, что пользователь Х 197 раз в день обновил у себя в клиентской программе грид с данными? зачем нужны эти сведения? что полезного мы можем из них почерпнуть? и стоит ли ради их получения увеличивать время разработки и просаживать производительность? - вот вопросы, ответы на которые хочется получить, а не общие рассуждения, что "мол, надо" и "мол, сделано".
1. здесь рассматривается достаточно узкий случай. Как правило, к базе можно доступиться не только через разработанную клиентскую программу, но и другими инструментамиэтот узкий случай и есть самая частая операция выборки данных из базы. Она выполняется по тыще раз на дню каждым пользователем и представления для таких гридов, как правило и являются одними из ( или даже самыми ) тяжёлыми выборками, а вы предлагаете к ним прикрутить ещё и лог.
Кстати, ответов на вопросы я так и не получил ))
ЗЫ сорри за многабукаф ))