Мы все еще используем старый классический ASP и хотим регистрироваться всякий раз, когда пользователь делает что-то в нашем приложении. Мы напишем общую подпрограмму, чтобы взять детали, которые мы хотим записать.
Должны ли мы регистрировать это, чтобы сказать txt файл с помощью FileSystemObject или зарегистрировать его в базе данных MSSQL?
Если база данных должна добавить новую таблицу в существующую базу данных или мы должны использовать отдельную базу данных?
Edit
В ретроспективе лучшим ответом является запись в файловую систему BOTH (сначала, сразу), а затем в централизованную базу данных (даже если она задерживается).
Обоснование написания файловой системы о том, что если внешняя инфраструктурная зависимость, такая как проблема с сетью, базой данных или безопасностью, мешает вам писать удаленно, по крайней мере, вы отступили, если сможете восстановить данные с жесткого диска веб-сервера ( что-то похожее на черный ящик в авиационной отрасли).
Фактически администраторы журналов предприятия, такие как Splunk, могут быть настроены на очистку файлов журнала локального сервера (например, как написано log4net, EntLib Logging Application Block и т.д.), а затем централизовать их в базе данных, доступной для поиска, где данные могут быть заминированы, отображены, показаны на информационных панелях и т.д.
Но с точки зрения операционной деятельности, где вполне вероятно, что у вас будет ферма веб-серверов и предполагается, что работают как локальная файловая система, так и механизмы удаленного управления базами данных, 99% -ный вариант использования для фактического поиска чего-либо в файле журнала все равно будет осуществляться через центральную базу данных (в идеале с достойной системой внешнего интерфейса, позволяющей запрашивать, собирать и даже графически отображать данные журнала).
Оригинальный ответ
Если у вас есть база данных, я бы рекомендовал использовать ее для записей аудита вместо файловой системы.
Обоснование:
severity, action type, user, date ...)select ... from Audits where ...) и GrepDelete from Audits where = Date ...)Решение об использовании существующего db или нового зависит от того, есть ли у вас несколько приложений (с их собственными базами данных) и хотите ли вы регистрировать/проверять все действия во всех приложениях централизованно, тогда централизованный db может иметь смысл.
Поскольку вы говорите, что хотите провести аудит активности пользователя, может быть целесообразным провести аудит в том же db, что и таблица/определение пользователей (если применимо).
Я согласен с вышеизложенным, возможно, с очевидным исключением из-за сбоев в регистрации базы данных, которые затрудняли бы регистрацию в базе данных. Это мне пришло в голову в прошлом, поскольку я имел дело с нечастыми, но регулярными отказоустойчивыми сетями.
Либо работает. Это зависит от ваших предпочтений.
У нас есть одна центральная база данных, где ВСЕ наши приложения регистрируют свои сообщения об ошибках. Каждое приложение, которое мы пишем, настраивается в таблице с уникальным идентификатором, а таблица журналов ошибок содержит ссылку на внешний ключ для AppId.
Это был ОГРОМНЫЙ бонус для нас, предоставляя нам одно место для мониторинга ошибок. Мы сделали это как файловую систему или отправили письма в контролируемый почтовый ящик в прошлом, но мы смогли создать довольно приятное веб-приложение для взаимодействия с журналами ошибок. У нас разные уровни ошибок, и у нас есть "подтвержденное" поле флага, поэтому у нас есть страница, где мы можем просматривать неподтвержденные события по степени тяжести и т.д.,
Глядя на ответы, я думаю, что ответ может быть и тем и другим.
Если это ошибка пользователя, которая может произойти во время ожидаемого использования (например, пользователь вводит недействительный адрес электронной почты и т.д.), это должно войти в базу данных, чтобы воспользоваться легкими запросами.
Если это ошибка кода, которая не должна произойти (невозможно получить имя пользователя для входа в систему), это должно быть зарезервировано для файла txt.
Это также красиво разбивает ошибки между некритическими и критическими. Надеемся, что список критических ошибок останется маленьким!
Я создаю быстрый прототип нового проекта прямо сейчас, поэтому теперь я буду придерживаться txt.
В другом примечании, электронная почта отлично подходит для этого. Возможно, вы можете просто отправить их на учетную запись "ошибка", а не хранить их локально. Однако это разделяет риск базы данных плохих соединений.
Должны ли мы регистрировать это, чтобы сказать txt файл с помощью FileSystemObject или занести в журнал его в базу данных MSSQL?
Другая идея - записать файл журнала в XML и затем запросить его с помощью XPath. Мне нравится думать, что это лучшее из обоих миров.