记录到文件还是数据库更好?
我们仍在使用旧的 Classic ASP,并且希望在用户在我们的应用程序中执行某些操作时进行记录.我们将编写一个通用子例程来获取我们想要记录的详细信息.
We're still using old Classic ASP and want to log whenever a user does something in our application. We'll write a generic subroutine to take in the details we want to log.
我们应该使用 FileSystemObject
将其记录到例如 txt 文件还是将其记录到 MS SQL 数据库?
Should we log this to, say, a txt file using FileSystemObject
or log it to a MS SQL database?
在数据库中,我们应该在现有数据库中添加一个新表还是应该使用单独的数据库?
In the database, should we add a new table to the one existing database or should we use a separate database?
推荐答案
编辑
事后看来,更好的答案是登录到 BOTH 文件系统(首先,立即),然后登录到中央数据库(即使延迟).
In hindsight, a better answer is to log to BOTH file system (first, immediately) and then to a centralized database (even if delayed).
写入文件系统背后的基本原理是,如果网络、数据库或安全问题等外部基础设施依赖项阻止您远程写入,那么如果您可以从 Web 服务器的硬盘恢复数据,至少您有一个后备方案(类似于航空业中的黑匣子).
The rationale behind writing to file system that if an external infrastructure dependency like network, database, or security issue prevents you from writing remotely, that at least you have a fall back if you can recover data from the web server's hard disk (something akin to a black box in the airline industry).
事实上,像 Splunk 这样的企业日志管理器可以配置为抓取您的本地服务器日志文件(例如由 log4net
、EntLib Logging Application Block
等人编写),然后将它们集中在可搜索的数据库中,其中记录的数据可以被挖掘、绘制、显示在仪表板上等.
In fact, enterprise log managers like Splunk can be configured to scrape your local server log files (e.g. as written by log4net
, the EntLib Logging Application Block
, et al) and then centralize them in a searchable database, where data logged can be mined, graphed, shown on dashboards, etc.
但是从操作的角度来看,您很可能会有一个 Web 服务器场,并且假设本地文件系统和远程数据库日志记录机制都在工作,那么 99% 的用例是实际尝试查找任何内容日志文件中的内容仍将通过中央数据库进行(理想情况下,有一个不错的前端系统可以让您查询、汇总甚至绘制日志数据).
But from an operational perspective, where it is likely that you will have a farm of web servers, and assuming that both the local file system and remote database logging mechanisms are working, the 99% use case for actually trying to find anything in a log file will still be via the central database (ideally with a decent front end system to allow you to query, aggregate and even graph the log data).
原答案
如果您有数据库,我建议您将其用于审计记录而不是文件系统.
If you have the database in place, I would recommend using this for audit records instead of the filesystem.
理由:
- 数据的类型化和规范化分类(
严重性、操作类型、用户、日期...
) - 更容易找到审计数据(
select ... from Audits where ...
)vs Grep - 更容易清理(例如
Delete from Audits where = Date ...
) - 更容易备份
使用现有数据库或新数据库的决定取决于 - 如果您有多个应用程序(具有自己的数据库)并希望集中记录/审核所有应用程序中的所有操作,那么集中式数据库可能是有意义的.
The decision to use existing db or new one depends - if you have multiple applications (with their own databases) and want to log / audit all actions in all apps centrally, then a centralized db might make sense.
既然您说要审核用户活动,那么在与您的用户表/定义(如果适用)相同的数据库中进行审核可能是有意义的.
Since you say you want to audit user activity, it may would make sense to audit in the same db as your users table / definition (if applicable).
相关文章