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 回答