使用SQL Server进行应用程序日志记录 优点缺点？

他们很少阅读：在开发应用程序的错误消息，诊断消息或应用程序正在生产中对用户报告的问题或错误进行分类时。

(这是一个严格的应用程序日志，安全记录保存在其他地方。)

但是当他们被阅读时，他们是屁股的痛苦。即使使用Perl，即使使用Perl也可以使用10MB的文本文件：文件中的字段(事务ID，用户ID等)很有用，但只是文本。消息按顺序写入，一次像一次一样，因此当尝试跟踪特定事务或用户时，交错的活动都被混合在一起。

我正在寻找关于这个话题的想法。任何人使用SQL数据库完成应用程序级日志记录并且喜欢它？讨厌吗

解决方法

主要原因是这样的：一旦出现错误，您就可以使用它来调试您的应用程序验证后，一个好的日志将是最有用的。为了能够做到这一点，你需要确保记录本身是可靠的。为了使任何系统可靠，一个好的开始是保持简单。

所以有一个简单的基于文件的日志只需几行代码(打开的文件，附加行，关闭文件或保持打开，重复…)通常会更加可靠和有用的将来，当你真的需要它上班。

另一方面，成功记录到SQL服务器将要求更多组件正常工作，并且将会有更多可能的错误情况，您将无法记录所需的信息，只是因为日志基础设施本身不会工作。最糟糕的是：日志过程中的故障(如数据库损坏或死锁)可能会影响应用程序的性能，然后您将遇到一个次要组件阻止应用程序执行其主要功能的情况。

如果您需要对日志进行大量分析，并且您不舒服使用基于文本的工具(如grep)，请将日志保存在文本文件中，并定期将其导入SQL数据库。如果SQL失败，则不会丢失任何日志信息，甚至不会影响应用程序的功能。那么可以在数据库中进行所有的数据分析。

我认为这些是为什么我不记录到数据库的主要原因，尽管我以前做过这一切。希望它有帮助。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!