我在其中一个团队中遇到了一个问题.其中一个人在我看来有点SQL快乐,并希望将一个小型python FTP下载器生成的日志信息存储到数据库中,而不仅仅是很好的格式文本文件.现在我一直认为只有在加速数据库时才能使用数据库,或者为数据提供更可靠的接口.你有什么看法？
谢谢!
编辑:在这个特定的实例中,数据将每天增长大约100行,并被处理一次并丢弃.虽然这个案例是直接关注的,但我对一般答案更感兴趣.
编辑2:感谢您的所有回复!我用最多的选票作为答案标记了答案,因为我觉得它简明扼要地说明了你们所做的大部分要点,但我会观察并看看是否还有其他问题.
Rob*_*vey 22
如果要运行数据报告或稍后询问问题,数据库是一种合理的选择,尤其是在同一数据库文件中存储多个运行以查找趋势时.
如果您只是编写来自单个运行的日志,并且在查看后不关心数据,则数据库可能没有意义.
dar*_*ron 15
看,很多"想到未来需求"的论点都是过度工程的过时.吻.
在这方面,你唯一需要做的就是解决未来的需求就是简单地编写你的日志记录例程,以便以后很容易将它完全重定向到其他东西.DIY文本,syslog类型服务或DB.记住这个概念,但除了你现在需要的东西之外,不要写任何东西.
根据你的描述,听起来你应该只使用一个简单的文本文件.
平面文件是一种数据库形式.
选择预先存在的DBMS而不是自己动手的原因主要是你的时间花在问题领域而不是重新发明轮子.
如果您的需求很简单并且您不想花费很多钱,那么您可以随时使用低端或OSS数据库.
鉴于丰富的日志文件分析程序以及纯文本的服务器日志数量,已经确定纯文本日志文件可以扩展并且相当容易查询.
通常,大多数SQL数据库都经过优化,可以稳健地更新数据,而不是简单地附加到时间序列的末尾.该实现假定数据不应该重复,并且存在与需要强制执行的其他关系/表的引用相关的完整性约束.由于日志永远不会更新现有条目,因此没有可以违反的约束或级联删除,因此您将永远不会使用它.
您可能更喜欢用于事务可伸缩性的数据库 - 比如说您希望将许多日志集中到一个数据库中,因此实际上获得了一些并发性(尽管它不是问题的固有内容 - 在一台服务器上使用单独的日志也可以允许这样做,但是您可以将它们合并到所有系统的总数中).
使用SQL数据库比仅添加一个或两个文件并调用fflush要复杂一些.OTOH如果您非常习惯使用SQL并且已经在项目中使用数据库,那么使用数据库进行日志记录的开销也很小.
数据库提供可扩展性，而平面文件则不提供。如果您开发的应用程序需要在 2 年内完成更多任务，会发生什么情况？
数据库还提供许多其他好处，包括权限级别和内置备份，否则您必须手动配置，从而增加需要完成的工作。如果可以的话，我总是会选择数据库而不是平面文件。总是。
当日志文件导致磁盘空间不足时会发生什么？
将日志信息存储在数据库表中的优点：
我觉得我可以在这个话题上持续几个小时。说真的，采用标准的日志记录方法并使用数据库表，您不会后悔的。
我脑海里浮现出许多问题,可以指导答案,最终引导你自己的问题.
没有一个解决方案,数据库可能会进行优化,但同样可能非常有效.
一个.
作为客户端/服务器和现在的n层应用程序的开发人员,我非常喜欢数据库系统的强大功能,可靠性和速度.说完这个后,我对在db中进行进程日志记录非常犹豫.在db中存储复杂工作流的当前状态或关键状态转换非常好,但是对DB中的所有步骤进行loggin/tracing可能是个问题.如果记录的原因是能够跟踪故障并可能调试系统,我需要能够在最恶劣的情况下处理我的"日志".如果我的db/network /怎么办？在某种程度上不起作用.如果我可以进入服务器,一个文本文件让我用vi/emacs/notepad/*进行调试.不是最强大的工具集,但始终可用.格式良好的日志文件也可以使用grep/awk/sed等生成报告.同样,不是最强大但随时可用的.最后,如果我希望在故障情况下使用我的日志记录,我需要尽可能高的可用性,并假设我处于故障状态,我不能假设我的数据库仍然在运行.