是否更好地登录到文件或数据库？

Question

我们仍在使用旧的经典ASP，并希望在用户在我们的应用程序中执行某些操作时进行记录。我们将编写一个通用子例程来接收我们要记录的细节。

我们是否应该使用FileSystemObject将其记录为txt文件或将其记录到MSSQL数据库？

如果是数据库，我们是应该向现有数据库添加新表还是应该使用单独的数据库？

Answer 1

修改

事后看来，更好的答案是登录 BOTH 文件系统（首先，立即），然后登录到集中式数据库（即使延迟）。

写入文件系统的理由是，如果外部基础架构依赖性（如网络，数据库或安全问题）阻止您远程编写，那么至少如果您可以从Web服务器的硬盘恢复数据，则至少会有后退（类似航空业黑箱的东西。）

事实上，可以将Splunk之类的企业日志管理器配置为抓取本地服务器日志文件（例如，由log4net，EntLib Logging Application Block等编写）然后集中化它们位于可搜索的数据库中，可以在其中挖掘，绘制图表，显示在仪表板上等。

但从操作角度来看，您可能会拥有一个Web服务器场，并假设本地文件系统和远程数据库日志记录机制都在工作，99％的用例实际上是为了找到任何东西在日志文件中仍然会通过中央数据库（理想情况下有一个不错的前端系统，允许您查询，聚合甚至绘制日志数据）。

原始答案

如果您有数据库，我建议将其用于审计记录而不是文件系统。

<强>理由：

• 数据分类和规范化分类（severity, action type, user, date ...）
• 更容易找到审核数据（select ... from Audits where ...）与Grep
• 更容易清理（例如Delete from Audits where = Date ...）
• 更容易备份

使用现有数据库或新数据库的决定取决于 - 如果您有多个应用程序（具有自己的数据库）并且希望集中记录/审核所有应用程序中的所有操作，则集中式数据库可能有意义。

由于您说您要审核用户活动，因此在与用户表/定义相同的数据库中进行审核（如果适用）可能是有意义的。

Answer 2

我同意上述内容，可能明显的例外是日志数据库故障，这会使登录数据库成为问题。这对我来说已经出现了，因为我正在处理不经常但常规的网络故障转移。

Answer 3

要么有效。这取决于您的偏好。

我们有一个中央数据库，我们所有的应用都会记录他们的错误消息。我们编写的每个应用程序都在一个具有唯一ID的表中设置，错误日志表包含对AppId的外键引用。

这给我们一个监控错误的地方带来了巨大的好处。我们之前已将其作为文件系统或通过向受监控的收件箱发送电子邮件来完成，但我们能够创建一个相当不错的Web应用程序来与错误日志进行交互。我们有不同的错误级别，并且我们有一个“已确认”标志字段，因此我们有一个页面，我们可以按严重程度等查看未确认的事件，

Answer 4

看看回答，我认为答案实际上可能都是。

如果是在预期使用期间可能发生的用户错误（例如，用户输入无效的电子邮件等），则应该进入数据库以利用简单的查询。

如果是不应该发生的代码错误（无法获取登录用户的用户名），则应该为txt文件保留。

这也很好地将错误分为非关键和批判。希望关键错误列表保持很小！

我现在正在创建一个新项目的快速原型，所以我现在会坚持使用txt。

另一方面，电子邮件非常适合这一点。可以说，您可以通过电子邮件将其发送到“bug”帐户，而不是将其存储在本地。但是，这会分担数据库连接不良的风险。

Answer 5

  

我们是否应该使用FileSystemObject将其记录为txt文件或记录它   到MSSQL数据库？

另一个想法是用XML编写日志文件，然后使用XPath查询它。我喜欢认为这是两全其美的。