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

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

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

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

22
asp-classic logging sql-server

5 ответов

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

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

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

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

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

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

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

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

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

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

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

22

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

6

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

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

Это был огромный бонус для нас, давая нам одно место для мониторинга ошибок. Мы сделали это как файловая система или отправив электронные письма в отслеживаемый почтовый ящик в прошлом, но мы смогли создать довольно хороший веб-приложение для взаимодействия с журналами ошибок. У нас разные уровни ошибок, и у нас есть "признанное" поле флага, поэтому у нас есть страница, где мы можем просматривать непризнанные события по серьезности и т. д.,

5

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

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

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

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

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

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

2

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

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

1