AlexG ну и джругую полезную информацию
И кому эта информация будет интересна? А самое главное чем?
Логировать кто последний залез в мою чашку с ногами и плюнул в нее? А толку?

Если валить в одно место логи на редактирование/удаление с разных таблиц, то это будет помойка, в которой черт ногу сломит. Ведь если появилась мысль о логгировании изменений, значит это кому то нужно. А следовательно на эту таблицу с логами надо навершивать интерфейсы для просмотра, всякие фильтры и и отчеты, причем такие, чтобы пользователи понимали об чем речь, собственно говоря.
На мой взгляд универсализация в этом месте ни к чему хорошему не приведет. Для каждой таблицы нужно сначала ответить на вопросы: кто может делать edit/delete, кто смотрит логи по этим операциям, надо ли этому товарищу знать предыдущее значение при выполнении редактирования, надо ему ли знать данные удаленной записи.
Практика показывает, что большей частью на редактирование надо знать "кто папа" (типа кто последний). На удаление - "кто накосячил". В первом случае добавляется поле User ID Edit, во втором операцию "удалить", выполняемую пользователем, заменяете на пробивание флага типа "Deleted" и реальное удаление записей делаете в другой процедуре при выполнении какого-нибудь дополнительного действия типа "проверено - удалять можно".
Полное логирование всех изменений требуется очень в ограниченных случаях и там лучше создать хистори для отдельной таблицы и сносить в нее запись целиком (или только некоторые поля) при выполнении определенных действий.

YBW tygra авторПрактика показывает, что большей частью на редактирование надо знать "кто папа" (типа кто последний). На удаление - "кто накосячил". В первом случае добавляется поле User ID Edit, во втором операцию "удалить", выполняемую пользователем, заменяете на пробивание флага типа "Deleted" и реальное удаление записей делаете в другой процедуре при выполнении какого-нибудь дополнительного действия типа "проверено - удалять можно".
Вы по-русски уж, а то бред какой-то, особенно про удаление.
-- Tygra's --

ИМХО типовая схема типовой подход - и так все понятно

Ну видимо товарисчу требуетсяч перевод:
1. "Кто папа" - означает "кто последний редактировал запись". В том случае, если имеется n (где n>1) равноправных пользователей, которые могут изменять некоторое поле, неважно знать какое значение было раньше, но важно знать кто последний выполнил апдейт.
2. "Кто накосячил" - означает "кто удалил эту сверхважную запись". В том случае, если имеется n (где n>1) равноправных пользователей которые могут удалять записи, но есть при этом один суперпользователь, который принимает окончательное решение об удалении записи, важно, чтобы случайно не удалили нужную запись. В этом случае простые пользователи ничего не удаляют, а только скидывают в "корзину". А уже суперпользователь выполняет аудит этой корзины и окончательно принимает решение об удалении или восстановлении той или иной записи.
К каждой таблице хистори вешать - замучаешься таблицы создавать :)

guest_20040621 Т. е. статья в числе прочего описывает фичу, которая реально хм... скажем корректно: совсем не нужна; вместо этого нужно использовать чуть более сложное и затратное, но логичное и удобное решение.



Поддерживаю. Просто аудит изменений без четких ответов на вопрос "Кому это надо и как он это будет этим пользоваться" может принести пользу только в удовлетворении параноидальных наклонностей администратора приложения.

Необходимости в логгировании изменений можно избежать, проектируя изначально доступ операциям, приводящим к изменениям в данных, либо же сами операции. Это конечно значительно сложнее, чем просто вести лог изменений, но с точки зрения функциональности куда эффективнее.