Аудит корпоративных данных [закрыто]

Question

Наше текущее корпоративное решение — это приложение ASP.NET MVC, управляемое Entity Framework.Есть пара ссылок о том, как подключиться к событиям изменений для аудита.Меня это не особо интересует.

Меня интересует архитектура аудита на уровне предприятия.Те из вас, у кого есть боевые раны на уровне предприятия, каковы были ваши решения для аудита?Вы сериализуете объекты в базах данных в рамках.Вы настраиваете триггеры базы данных для аудита таблиц?Используете ли вы отдельную базу данных, чтобы рост аудита не влиял на базу данных вашего приложения?Меня интересуют проверенные и надежные решения.Я знаю, что у нас есть варианты выбора технологии (EF), но меня в первую очередь интересует фундамент.

Ссылки будут очень признательны.

Answer 1

Я видел несколько решений, но больше всего мне понравилась простота:

• Создайте таблицы аудита, которые отражают каждую исходную таблицу, добавив несколько дополнительных столбцов для отслеживания даты и типа изменения (вставка, обновление или удаление, если вы это поддерживаете) и пользователя, внесшего это изменение.Удалите все ограничения и индексы (если вы не планируете выполнять много поисков).

• Внутри логики обновления таблицы (мы использовали процедуры, но нет причин, по которым это нельзя было бы сделать с помощью OR/M или другого уровня персистентности, учитывая соответствующие перехватчики), записывайте как в исходную таблицу, так и в таблицу аудита.

Это имеет множество преимуществ, но самым большим из них (по моему мнению) является отсутствие необходимости беспокоиться или писать весь код для управления транзакционной целостностью парных операций записи на клиенте.

Answer 2

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

TableName, PrimaryKeyValue, ModifiedColumn, OldValue, NewValue, ChangeUser, Дата изменения

Теперь, это прекрасно работает для скорости аудита, в нашем коде у нас есть общий интерфейс для автоматической реализации ведения журнала аудита, но из " review " с точки зрения, это не "самый быстрый" способ получить информацию обратно. (Конечно, мы на самом деле ничего не сделали, чтобы посмотреть журнал аудита ...)

Answer 3

Недавно нам пришлось решить эту проблему на нашем предприятии. Мы были обязаны иметь возможность вернуться к предыдущим версиям тоже.

В итоге мы провели аудит бизнес-объектов, а не таблиц в SQL. Мы в основном сериализуем записи в БД и отслеживаем изменения, внесенные из одной версии в другую. Этот подход позволяет нам возвращать предыдущие версии в бизнес-объекты, а затем возвращать их обратно, вызывая те же операции сохранения. Эта функциональность для возврата обратно будет перенесена на ответственность приложений, потому что она должна решаться здесь, в противном случае нашему сервису может понадобиться узнать слишком много деталей об участвующих приложениях. Предоставляются операции Serivce для извлечения записей по версиям, по датам, истории просмотров и, конечно, для аудита изменений. Это подход выбора для разных групп приложений и разных сущностей внутри (не все в БД нужно проверять, так зачем это делать).

Затем мы создаем облегченный веб-сайт, который общается со службой и может отображать все версии. Мы создали механизм, показывающий добавления / обновления / удаления для сравнения между версиями (действительно классное представление пользовательского интерфейса), что позволяет пользователям видеть, кто что изменил и когда. Служба может отправить ссылку на URL-адрес, чтобы просмотреть версии объекта. Это позволяет нашим приложениям webaps + winform / wpf запускать браузер, чтобы пользователи могли видеть изменения.

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