3

我在一家电子商务公司工作。我们的 DBA 最近告诉我,使用 SQL 进行日志记录是一种不好的做法,并建议使用平面文件和 grepping 代替。我以前从未听说过登录 SQL 是一种不好的做法,而且我在网上找不到任何可以证实这一点的东西。

当我说日志时,我的意思是记录用户操作,如登录、更改帐户信息等,以及他们的用户代理、IP 地址、帐户 ID 和事件信息等数据。

虽然随着时间的推移会导致很多行,但如果客户有问题,它可以非常容易地搜索。

登录 SQL 是一种不好的做法,是否最好登录到文件?

谢谢。

4

5 回答 5

3

这样做的唯一问题是增加了数据库负载和增加了磁盘空间。除此之外,没有什么能阻止你这样做。实际上,能够查询您的日志并使其保持一致且易于备份是非常方便的。

与平面文件相比,您可以使用 SQL 在日志中添加更多结构。例如,您可以有以下列:

  • ID
  • 约会时间
  • 事件代码
  • 信息
  • 机器名称
  • HttpRequestID
  • 用户名
  • 用户身份
  • AdditionalDataXML:可查询的 XML 列,其中包含有关事件的结构化数据

很方便。我推荐它。

为什么您的 DBA 会抗拒?好吧,他说服你放弃它没有坏处。他没有得到一张漂亮的日志记录表的好处。但他必须维持它。激励是不对称的。

作为缓解措施,您可以每晚TRUNCATE TABLE清除日志项。也许在这样做之前将它们导出(bcp.exe)。

于 2012-06-14T17:44:31.237 回答
3

也许他指的是使用触发器进行记录是不好的做法。触发器会导致很多意想不到的效果,并且可以被认为是不好的做法。

除了 SQL 通常用作日志存储之外,因此(如果您有足够的存储空间)这没有任何问题。

于 2012-06-14T17:44:47.803 回答
3

交易存在问题。日志记录将成为事务的一部分,因此如果回滚,日志也会消失。

为了登录 SQL 工作,您需要设置一个单独的 DBMS 会话,这会使事情变得更加复杂。平面文件没有事务。在磁盘已满的情况下,它们也会(合理地)优雅地失败。您可以在不干扰交易的情况下管理(清除)它们。

而且,由于日志记录基本上是仪器,因此最好不要过多地干扰被监视的过程。

最后:如果您真的想要 SQL 的易用性,您总是可以选择将平面文件重新导入 DBMS 表。在单独的交易中。

顺便说一句:上述答案与维护历史无关。这是一个完全不同的球赛,应该被视为 DBMS+ 应用程序的一部分。

于 2012-06-14T17:59:01.450 回答
3

看起来您的 DBA 宁愿将所有日志记录(SQL 或应用程序)转到一个平面文件以使用 grep。我完全不同意。我个人发现 SQL 比使用 grep 更容易搜索。该条款

  WHERE event_time BETWEEN '1/1/2012 1:00AM' AND '1/1/2012 1:10AM'

比你从 grep 获得的任何东西都更容易编写和检索(假设索引)。

Microsoft 不认为日志记录对数据库有害,他们的企业库支持它: http: //msdn.microsoft.com/en-us/library/ff664543 (v=pandp.50).aspx

IIS 也支持它,大多数主要的日志库都包含数据库支持。

存储问题本身不一定是问题,您要么登录到应用程序中的文件,要么登录到数据库中的数据库文件。我看到的主要问题是在您进行事务时它是否会变得过于昂贵,并且如上所述,回滚事务导致回滚日志记录的问题。

于 2012-06-14T19:47:59.213 回答
0

我以前没有听说过它被描述为“不好的做法”,你总是可以设置一个工作来清除超过一定年龄的记录(例如,我们只保留最后一个月的日志)。我想这也取决于谁将查看日志,因为并非所有应用程序支持人员都知道 SQL,而他们可以轻松地阅读文本文件。

于 2012-06-14T17:53:35.020 回答