Лучше войти в файл или базу данных?
Мы ' Вы все еще используете старый классический ASP и хотите войти, когда пользователь что-то делает в нашем приложении. Мы напишем стандартную подпрограмму, чтобы взять детали, которые мы хотим записать.
Должны ли мы записать это, чтобы сказать txt файл, используя FileSystemObject, или записать его в базу данных MSSQL?
Если в базу данных, мы должны добавить новая таблица для одной существующей базы данных или мы должны использовать отдельную базу данных?
3 ответа
Edit
In Оглядываясь назад, лучший ответ - войти в ОБА файловую систему (сначала сразу), а затем в централизованную базу данных (даже если это произойдет с задержкой).
Обоснование записи в файловую систему состоит в том, что если зависимость внешней инфраструктуры, такая как сеть, база данных или проблема безопасности, не позволяет вам выполнять удаленную запись, то, по крайней мере, у вас есть запасной вариант, если вы можете восстановить данные с жесткого диска веб-сервера ( что-то вроде черного ящика в авиастроении).
Фактически, корпоративные менеджеры журналов, такие как Splunk , могут быть настроены для очистки файлов журналов локального сервера (например, как написано log4net , EntLib Блок приложения регистрации ] и др.), а затем централизовать их в базе данных с возможностью поиска, где зарегистрированные данные могут быть извлечены, построены в виде графиков, отображены на информационных панелях и т. д.
Но с операционной точки зрения, где вероятно, что у вас будет ферма веб-серверов, и если предположить, что и локальная файловая система, и механизмы ведения журнала удаленной базы данных работают, 99% вариант использования для фактических попыток найти что-либо в файле журнала по-прежнему будет осуществляться через центральную базу данных (в идеале с приличной системой внешнего интерфейса, позволяющей запрашивать, агрегировать и даже отображать данные журнала).
Исходный ответ
Если у вас есть база данных, я бы рекомендовал использовать ее для записей аудита вместо файловой системы.
Обоснование:
- типизированная и нормализованная классификация данных (
серьезность, тип действия, пользователь, дата ...) - легче найти данные аудита (
выберите .. .из аудита, где ...) по сравнению с Grep - легче очистить (например,
Удалить из аудита, где = Дата ...) - легче сделать резервную копию
Решение использовать существующую базу данных или новую зависит от того, есть ли у вас несколько приложений (с собственными базами данных) и вы хотите централизованно регистрировать / проверять все действия во всех приложениях, тогда централизованная база данных может иметь смысл.
Поскольку вы говорите, что хотите проводить аудит активности пользователей, возможно, имеет смысл проводить аудит в той же базе данных, что и ваша таблица / определение пользователей (если применимо).
Я согласен со всем вышесказанным, за исключением, возможно, очевидного исключения - протоколирования сбоев базы данных, что сделает протоколирование в базе данных проблематичным. В прошлом я сталкивался с этим, когда имел дело с нечастыми, но регулярными сбоями сети.
Либо работает. Это зависит от ваших предпочтений.
У нас есть одна центральная база данных, в которой ВСЕ наши приложения регистрируют сообщения об ошибках. Каждое приложение, которое мы пишем, настроено в таблице с уникальным идентификатором, а таблица журнала ошибок содержит ссылку внешнего ключа на AppId.
Это было ОГРОМНЫМ бонусом для нас, поскольку мы получили одно место для отслеживания ошибок. Раньше мы использовали файловую систему или отправляли электронные письма в отслеживаемый почтовый ящик, но нам удалось создать довольно хорошее веб-приложение для взаимодействия с журналами ошибок. У нас разные уровни ошибок, и у нас есть поле «подтверждено», поэтому у нас есть страница, на которой мы можем просматривать неподтвержденные события по серьезности и т. Д.,