Лучше войти в файл или базу данных?

Question

Мы все еще используем старый классический ASP и хотим регистрироваться, когда пользователь что-то делает в нашем приложении.Мы напишем универсальную подпрограмму, чтобы взять детали, которые мы хотим записать.

Должны ли мы записать это, чтобы сказать txt-файл, используя FileSystemObject или зарегистрировать его в базе данных MSSQL?

Еслибаза данных, мы должны добавить новую таблицу в одну существующую базу данных или мы должны использовать отдельную базу данных?

Answer 1

Редактировать

В ретроспективе лучшим ответом будет войти в ОБА файловую систему (сначала, немедленно), а затем в централизованную базу данных (даже если она задерживается)).

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

Фактически, менеджеры журналов предприятия, такие как Splunk , могут быть настроены для очистки файлов журнала локального сервера (например, какнаписано log4net, EntLib Logging Application Block и др.), а затем централизовать их в доступной для поиска базе данных, где записанные данные можно добывать, графически отображать на информационных панелях и т. д.

Но с точки зрения эксплуатациигде, вероятно, у вас будет ферма веб-серверов, и предполагается, что как локальная файловая система, так и механизмы ведения журналов удаленной базы данныхПри работе в 99% случаев для фактической попытки найти что-либо в файле журнала все равно будет использоваться центральная база данных (в идеале, с приличной интерфейсной системой, позволяющей запрашивать, агрегировать и даже отображать данные журнала).

Оригинальный ответ

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

Обоснование:

• типизированная и нормализованная классификация данных (severity, action type, user, date ...)
• легче найти данные аудита (select ... from Audits where ...) против Grep
• itлегче очистить (например, Delete from Audits where = Date ...)
• проще создать резервную копию

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

Поскольку вы говорите, что хотите проверять активность пользователей, возможно, имеет смысл проводить аудит вта же база данных, что и у вашей таблицы пользователей / defначало (если применимо).

Answer 2

Я согласен с вышеизложенным, возможно, с очевидным исключением из-за регистрации ошибок базы данных, которые затрудняют регистрацию в базе данных. Это возникало у меня в прошлом, когда я имел дело с редкими, но регулярными отказами сети.

Answer 3

Либо работает. Это зависит от ваших предпочтений.

У нас есть одна центральная база данных, где ВСЕ наши приложения регистрируют свои сообщения об ошибках. Каждое приложение, которое мы пишем, настраивается в таблице с уникальным идентификатором, а таблица журнала ошибок содержит ссылку на внешний ключ для AppId.

Это был ОГРОМНЫЙ бонус для нас, предоставив нам одно место для отслеживания ошибок. В прошлом мы делали это в виде файловой системы или путем отправки электронных писем в отслеживаемую папку «Входящие», но нам удалось создать довольно приятное веб-приложение для взаимодействия с журналами ошибок. У нас разные уровни ошибок, и у нас есть поле «подтвержденного» флага, поэтому у нас есть страница, где мы можем просматривать неподтвержденные события по серьезности и т. Д.,

Answer 4

Глядя на ответы, я думаю, что ответ может быть на самом деле оба.

Если это ошибка пользователя, которая может произойти во время ожидаемого использования (например, пользователь вводит недопустимый адрес электронной почты и т. Д.), Она должна войти в базу данных, чтобы воспользоваться простыми запросами.

Если это ошибка кода, которая не должна возникать (невозможно получить имя пользователя, вошедшего в систему), это следует зарезервировать для текстового файла.

Это также хорошо разделяет ошибки между некритическими и критическими. Надеюсь, список критических ошибок останется маленьким!

Я сейчас создаю быстрый прототип нового проекта, поэтому сейчас я буду придерживаться txt.

С другой стороны, электронная почта отлично подходит для этого. Возможно, вы можете просто отправить их по электронной почте на учетную запись «ошибки», а не хранить их локально. Однако это разделяет риск плохих соединений с базой данных.

Answer 5

Должны ли мы регистрировать это, чтобы сказать текстовый файл, используя FileSystemObject или зарегистрировать его в базе данных MSSQL?

Другая идея состоит в том, чтобы написать файл журнала в XML и затем запросить его с помощью XPath,Мне нравится думать, что это лучшее из обоих миров.