Используя только технологии Microsoft (MS SQL Server, C#, EAB и т. д.), если вам необходимо отслеживать изменения, внесенные в запись в базе данных, какую стратегию вы будете использовать? Триггеры, АОП на DAL, Другое? А как вы будете отображать собранные данные? Есть ли закономерность в этом? Есть ли инструмент или фреймворк, которые помогут реализовать такое решение?
Аудит изменений записей в базах данных SQL Server
Ответы (3)
Проблема со сбором измененных данных заключается в том, что он недостаточно гибок для реального аудита. Вы не можете добавить нужные столбцы. Кроме того, он по умолчанию сбрасывает записи каждые три дня (вы можете изменить это, но я не думаю, что вы можете хранить их вечно), так что вам придется выполнять дублирование записей в реальную таблицу аудита, если вам нужно хранить данные для долгое время, что типично для необходимости аудита записей (мы никогда не сбрасываем наши аудиторские записи).
Я предпочитаю триггерный подход. Вы должны быть осторожны при написании триггеров, чтобы гарантировать, что они захватят данные, если несколько записей будут изменены. У нас есть две таблицы для каждой проверяемой таблицы: одна для хранения даты и времени и идентификатора пользователя или процесса, предпринявшего действие, и одна для хранения старых и новых данных. Поскольку мы делаем много процессов записи, это очень важно для нас. Если кто-то сообщает об одной плохой записи, мы хотим увидеть, был ли это процесс, который внес изменение, и если да, то какие другие записи также могли быть затронуты.
Во время создания процесса аудита создайте сценарии для восстановления набора проверенных данных до старых значений. Гораздо проще сделать это, когда вы находитесь под прицелом, чтобы исправить ситуацию, если у вас уже есть эта настройка.
person
HLGEM
schedule
16.03.2011
Если я правильно понял, вы на самом деле используете этот подход в системе производственной среды, не так ли? Если это так, подход триггера эффективен с точки зрения скорости записи?
- person GRGodoi; 16.03.2011
Да, мы используем в производстве. Это база данных среднего размера, и она немного замедляет работу, но не сильно (если вы правильно написали код триггера) для изменений, которые вносит пользователь, она замедляет наш массовый импорт (наш массовый импорт настроен так, чтобы не избежать триггеров ) больше, но пользователь этого не заметит. У нас есть нормативные требования, которые диктуют этот подход, сбор данных об изменениях просто не фиксирует все, что нам нужно. Мы также используем отслеживание изменений, но для другой цели.
- person HLGEM; 16.03.2011
Не позволил бы мне указать размер, который я считаю средней базой данных, но наша БД, использующая этот процесс в prod, составляет около 185 гигабайт и имеет тысячи пользователей.
- person HLGEM; 16.03.2011
Sql Server 2008 R2 имеет встроенный поиск Change Data Capture в онлайн-книгах.
person
Rikalous
schedule
16.03.2011
Большой! Я посмотрю на это.
- person GRGodoi; 16.03.2011
Возможно, это непопулярное мнение, но я все равно его выскажу.
Я предпочитаю хранимые процедуры для всех операций записи в базу данных. Если требуется аудит, он находится прямо в хранимой процедуре. Никакого волшебства вне кода не происходит, все, что происходит, документируется прямо в момент записи.
Если в будущем таблицу потребуется изменить, для внесения изменений необходимо обратиться к хранимой процедуре. Необходимость обновления аудита документируется тут же. А поскольку мы использовали хранимую процедуру, проще «версировать» как таблицу, так и ее таблицу аудита.
person
Tergiver
schedule
16.03.2011
Это плохая идея (как и то же самое из приложения). Вы не можете гарантировать, что все изменения будут проходить через хранимые процессы (или приложение), и поэтому у вас бесполезный аудит. Как вы думаете, они проходят через хранимую процедуру, когда нужно обновить миллион записей из-за какого-то изменения клиента? Как вы думаете, человек, мошеннически изменяющий записи, проходит через сохраненные процедуры? Крайне плохой выбор, весь аудит должен проводиться на уровне базы данных.
- person HLGEM; 16.03.2011
Нигде нет никаких гарантий, когда речь идет о базах данных. Конечно, вы можете немного укрепить ситуацию, но нет никакого способа помешать людям (включая будущих разработчиков) делать неправильные вещи. Если ваше приложение постоянно использует SP, это работает отлично.
- person Tergiver; 16.03.2011
Нет, это только кажется. И в рабочей среде не более 2 человек должны иметь возможность изменять триггеры (dba и резервный dba), поэтому у вас гораздо больше шансов поймать любого, кто вносит несанкционированные изменения, которые вы вообще не можете сделать с помощью хранимых процедур. Аудит предлагаемым вами способом чрезвычайно рискован, и ни один специалист по базам данных не допустит этого в своей системе. За 30 лет я ни разу не видел базу данных, в которой изменения данных не производились бы время от времени вне приложения.
- person HLGEM; 16.03.2011
Я хочу оставить этот ответ здесь, несмотря на отрицательную оценку, потому что считаю его полезным. Также полезно прочитать возражение @HLGEM.
- person Tergiver; 16.03.2011
