Database 用于日志记录的独立生产数据库

我在测试中有一个应用程序，它将部门Windows窗体应用程序的事件记录到SQL Server数据库。该应用程序即将投入生产。日志数据库与应用程序数据库完全分离

我的问题是，我真的需要创建日志数据库的生产版本，还是可以只将生产和测试事件记录到同一个数据库中？显而易见的答案是肯定的，当然我需要一个单独的数据库。您永远不希望测试环境和生产环境混合使用。但在本例中，写入数据库的数据实际上不是生产数据，确切地说，它只是记录我们用来解决问题的详细信息。它没有业务价值，如果数据被无意中删除或数据库暂时不可用，则不会丢失任何重要信息。在一个测试环境中拥有这一切将使我管理起来更加简单

因此，从正反两方面来看，在所有环境中使用单个日志数据库似乎是一个更好的解决方案。但感觉不太对劲。有谁能给我一个具体的理由说明为什么这是个坏主意吗？

我想说：

使用标准的日志记录方法（单个DLL或类似的方法），并在生产中实际容纳日志数据库

这样，您的日志数据库可以被视为“日志服务器”，所有应用程序（开发、登台、测试和产品）都可以登录到它，因为您使用的是经过审查的库

---

当然，您还必须注意不要让服务器泛滥…

首先，在数据库中保存日志是个坏主意。由于某种原因无法连接到数据库时会发生什么情况？我建议您使用log4net并实现RollingFileAppender。它们将日志条目写入文件，当文件达到某个限制时，log4net开始写入新文件。如果您对设置有任何疑问，请随时提问。我很乐意帮忙

我看不出把它放在开发框中有什么错，除非你的应用程序无法正确登录时会失败，或者除非记录的信息比你指出的更有价值

---

另一方面，将日志数据库保留在开发服务器上将有助于减轻生产服务器处理这些数据的负担，这在性能方面无疑是一个利好因素。

如果开发服务器停机，而prod未停机，日志可能无法工作。可以保证在您需要登录prod的关键事件发生时。在我们的例子中，prod和dev不在同一个物理位置，这意味着通过我们的网络发送日志数据，并导致管道瓶颈和古怪的网络人员

另外，如果您决定更改日志记录过程，该怎么办？当您进行新的开发时，整个prod过程可能会中断

---

有些时候，人们可能会阅读日志，对某个错误感到恐慌，忘记它发生在dev上。或者更糟糕的是，有些人可能会看到他们认为在dev上发生的错误，而实际上在prod上发生的错误。

谢谢。实际上，我使用的是一个封装log4net的DLL。我没有想到把一切都指向生产。好建议，我同意。将所有内容记录到生产中听起来很合理。如果您仍然依赖于生产服务器，那么这种方法不会降低您的应用程序的可靠性。有趣的一点。减轻生产负载是好的，但DBA可能不喜欢我将生产级流量路由到测试服务器。这一点很好。同样，只有当日志机制能够容忍日志数据库中的停机时，开发服务器的想法才是一个好主意。我实际上已经使用了很多RollingFileAppender。它们对web应用程序非常有效，但我在Windows应用程序中使用它们时遇到了权限和文件I/O问题（可能是我们企业独有的，但仍然存在实际问题），这就是为什么我要使用database appender。参见我的另一篇文章。@Artel:你说在数据库中保存日志一开始是个坏主意，为什么呢？，你能举例说明什么地方出了严重问题吗？