royt
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
alexsob
В принципе я сам за AUDIT обеими руками, но приходится работать в 9-ке - а там трудно (или даже невозможно) настроить аудит например конкретных колонок в конкретной таблице. Причем хотелось бы, чтобы работало примерно так (чтобы не было слишком большой избыточности информации):
если в такой-то таблице что-то делается с колонками скажем 1, 2 и 5, то в аудите появляется одна (!) строка с информацией об этом - а не отдельные строки на каждую колонку. Причем, если что-то делается только с колонками 1 и 5, то в строке аудита и должны упоминаться только колонки, что подвергаются изменениям. Насколько я понял, такого сделать нельзя, по крайней мере в девятке. Или я не прав?
Насчет DML/DDL. Можно ограничиться хотя бы DML. DDL тоже не помешал бы, но эти операции можно зарубить для критичных пользователей.
Цитата:| А оно надо именно в каком виде? А если надо, то для чего? |
Надо для аудита работы с важными и конфиденциальными данными - видеть, в случае разборок, кто чего менял. А также отслеживать, просто кто с чем работал. "Ловить" надо пользователей программы, не программеров/админов (хотя в идеале конечно ловить бы всех, но пока хотя бы ограничиться пользователями). Еще такой момент - хотелось бы отслеживать не только совершенные изменения (и попытки чтения некоторых объектов), но и неудавшиеся попытки (т.е. фиксировать в логе что была попытка изменения, но она не удалась), а триггерами это опять же сделать непросто.
Кстати, а Вы не могли бы привести иcходный код вашего UPDATED_BY (можно в PM)? Чтобы представлять, что и как можно вообще. Я честно говоря в оракле еще не слишком гибко мыслю, не знаю всех возможностей - чего и как можно в триггере "поймать" (например, если триггер навешен сразу на INSERT+UPDATE+DELETE - то как в триггере определить, какая именно из этих трех операций производится, ну и т.д. В общем проще сразу взглянуть на код триггера - уж из него думаю всё пойму без доп. вопросов, разберусь если что).
А как вы решаете следующую проблему - как гарантировать, что скрипт аудита запускается до или после других триггеров? Ведь в оракле порядок вызова триггеров вроде не оговаривается (т.е. если висят два триггера на одну операцию, то неизвестно, какой из них сработает первым). Или Вы и обычные действия ("рабочий прикладной код"), и код аудита - засовываете в один триггер?
Цитата:| На критические таблицы создаем таблицы истории изменения, в которые записывается кто, когда и что менял (муторно, а что делать?). |
Именно, что муторно... Пугает не то, что надо ручками работать, а то, что можно где-то чего-то недосмотреть. А вот если была бы какая визуальная тулза - покликал по нужным таблицам и колонкам, поставил галочки, указал какие операции аудитить - и на, получай audit- или triggers-скрипт. А незадействованные объекты сразу видны. В идеале примерно так себе представляю.
Если же писать ручками. Представим ситуацию: написали мы ручками скрипт (с помощью AUDIT или тригерров). Пускай структура базы достаточно большая, чтобы держать ее всю в голове - до сотни таблиц, в каждой от 5 до 20 колонок. Как после написания скрипта убедиться, что мы ничего не пропустили??? Трудно это - легко где-нибудь недосмотреть. Особенно если например на каждый INSERT/UPDATE/DELETE придется отдельные триггеры писать - их число вырастает сразу в несколько раз.
Цитата:| По поводу частого изменения структуры данных могу сказать одно: в продуманной системе структуры меняются крайне редко |
Это идеал, к которому конечно надо стремиться... Сейчас такая ситуация, что часть системы уже надо запускать, хотя структура еще не утрясена (и заказчик, и исполнитель это понимают, но оба идут на это, таковы реалии, в общем это вопрос не для этой темы).
Цитата:| Для построения модели данных ОБЯЗАТЕЛЬНО нужно использовать какое-нибудь CASE-средство типа Power Designer или хотя бы ErWin |
Это само собой. Вот и для аудита хотелось бы найти готовый инструмент.
ps. За сообщение спасибо, потдвердились почти все мои предположения, это тоже ценно.
Добавлено:
pochti
Цитата:| Сделал аудит на основе триггеров. Все просто замечательно. Не понимаю зачем еще что-то выдумывать? |
А можно посмотреть на пример триггера? Чтобы сразу понимать, какие вопросы задавать... Много тонких моментов по триггерам. Часть озвучил выше. |
Всего записей: 319 | Зарегистр. 18-08-2004 | Отправлено: 23:08 02-02-2007 | Исправлено: royt, 23:42 02-02-2007 |
|
у меня в неё встроен даунлоад мастер - он перехватывает закачку, я это могу отключить, но так как у меня хлипкий канал - то возможно и не получится продолжить закачку - есть у оперы такой каприз 
ld.поле1 
: Кстати, вопрос: допустим, в случае успешного завершения пользовательской транзации фиксируем этот факт, и при этом хотим удалить строку с информацией "Была предпринята попытка...", созданную в триггере INSERT - так вот как эффективнее найти эту строку? Т.е. если писать триггеры BEFORE и AFTER - как лучше "связать" между собой строки, формируемые этими триггерами (в рамках одной пользовательской/глобальной транзакции), по каким данным? Может существует какой-то "transaction id" (его можно было бы вставить в триггере BEFORE)?