数据库(RDBMS)中应该存储什么?

要回答这个问题,我们必须了解什么数据库存储提供了平面文件存储中不可用的内容。

1. 安全性-您可以存储资料,并确保更新、删除和视图受到控制
2. 审计-您可以跟踪谁进行了更改以及何时进行了更改
3. 分布式服务器-如果有多个应用程序服务器访问单个数据库,则可以避免在多个位置存储相同的数据。

如果这些是您需要的数据,最好将它们存储在数据库中。

应用程序日志

尽管将数据库中的数据限制在一个特定的时间范围(例如,转储/存档/压缩到统计所有超过3个月的数据)通常是一个好主意,但是将日志保存在数据库中可以非常快速和容易地分析数据。需要查看特定用户所做的操作吗?” 从用户为bla的日志中选择* “。需要找出系统在特定时间崩溃的原因吗?” 从日志中选择*,其中时间戳介于故障-1小时和故障+5分钟之间 “。

配置详细信息(如服务器IP地址等)

这取决于配置细节。有些是,有些不是。对于运行在多个客户机(如网站)上的应用程序有效的所有内容,以及可能经常更改的内容(如用户设置),都应该放在数据库中。对于或多或少的静态选项,我更喜欢使用配置文件。

系统信息(例如,shell脚本的名称、批处理作业的调度信息、批处理作业状态等)

我想这和配置细节差不多。如果它改变了:数据库。如果是static:config文件。shell脚本通常是静态的。计划信息和状态将随着时间的推移而变化。

我们在最近几个项目中将所有内容都存储在数据库中,在从开发到生产的过程中,这真的很有帮助,因为在应用程序本身中几乎没有需要配置的内容。

登录到数据库是有用的(例如log4j),因为它允许测试人员和分析人员广泛访问日志。

我想这取决于你的情况。数据库中存储的所有内容都会向系统添加一个cemplexity级别。读取文件比访问数据库更容易从代码中获取相同的信息。一个可能的规则是,如果拇指说,系统越大,应该在数据库中存储更多的信息。

一个小问题:99%的时间在数据库中存储配置是一个糟糕的主意。配置太重要,不能丢失到向南的DB连接:它需要100%防弹。

重新配置数据 在数据库中保留配置数据可能是一个好主意,这样可以更容易地编辑它并跟踪更改,但随后将其写入配置文件,以便实际程序读取。

• 为什么Apache必须知道关于数据库信息的任何信息才能进行配置?

• 数据库关闭时,FTP服务器为什么要停止工作?

回复:应用程序日志

如前所述,数据库可以使日志分析变得更容易,但我建议您考虑日志到文件并稍后批量导入模式。

性能问题

数据库非常适合获取随机数据位和放入随机数据位。日志数据主要不是随机写入的,而是连续的数据流,非常适合一行接一行地放入文件中。在写入数据时,不能超过平面文件的性能。也没有很多东西可以用平锉破。这还允许数据库集中精力完成实际的业务工作。

然后,您可以从文件中收集所有记录的数据,对其进行分析,进行任何必要的后期处理(例如从IP地址查找主机名),并将其放入数据库表中。你只要觉得有必要就经常这样做。对于我的网站,我真的不需要能够查看访问者的统计信息从一分钟变为另一分钟,所以我在晚上运行日志批处理。如果您需要最新的信息,您也可以每隔60秒运行一次批导入,但这仍然比为每个实际业务事务(当然,这取决于您记录了多少)执行一个额外的插入语句要好。

安全性

• 如果数据库是日志引擎,如何记录失败的数据库连接?

• 如果数据库在崩溃所涉及的事件中提前崩溃,您如何调查系统崩溃的原因?

所以我认为您应该考虑什么时候需要数据库中的日志数据,以及为什么需要数据库中的日志数据。

有一件事还没有被提到,如果你把诸如应用配置之类的东西推到数据库中,你就不能很容易地把它放在版本控制之下。

例如,一些CMS喜欢将HTML模板推送到数据库中,而不是作为文件。我个人认为这是个糟糕的设计。您不能将对模板所做的任何更改版本化,更糟的是,您所做的只是将真实文本编辑器中的内容复制并粘贴到浏览器中的弱文本编辑器中。

底线?问问你自己这是不是你想要的版本。如果是,请将其保存在数据库之外。如果没有,当然,把它放到数据库里。

注重易用性和维护性。 我存储在数据库中的唯一日志是由出错的触发器放在那里的,因为这是最简单的。但对于其他所有内容,搜索和解析文本日志更快更容易。如果应用程序崩溃,查看文本配置文件比查看数据库更容易, 特别是对于新的维护人员 . 对于一个新来的人来说,看到一个 app.properties 文件中 config/ 目录,而不知道在数据库中查找表。

此外,如果配置文件是文本文件,则可以比在数据库中更容易地将其存储在源代码管理中。相信我,这是非常重要的。您不希望调试已丢失导致错误的配置文件设置的应用程序。如果数据库崩溃或损坏,可能会丢失日志和配置设置,这可能使查找问题变得不可能。

如果你正在开发一个小型的静态网站,那么我会同意大多数已经提出的观点。但是,如果您有一个允许用户通过生产站点添加内容的网站,我会认为将配置放入数据库会使部署管道复杂化,因此最好不要将其放在数据库之外。

如果您试图将更新从dev推送到production,客户机将内容推送到production,并且您的配置和内容都在同一个数据库中,那么您只需要将配置数据覆盖的表作为目标。这“可以”是您的一项微不足道的额外工作,但这取决于应用程序的规模以及您是否在使用他人的代码。考虑Drupal站点。如果用户正在添加内容,那么对于部署,您需要针对特定的数据库表进行覆盖。因为Drupal有几个表(没有一个表的名称中有config),所以您需要做一些研究来找出哪些表可以被覆盖,哪些表不能覆盖。现在,如果Drupal的数据库布局发生了变化,会发生什么?部署管道可能会中断,这对您来说是额外的工作。添加新插件时会发生什么?更多配置表,因此需要更改部署脚本。为你做更多的工作。如果您最终离开这个项目,您应该将信息留给新的开发人员,以解释您在这些部署问题上做了什么。为你做更多的工作。

考虑一下,如果配置不在数据库中而是在应用程序目录结构中,会发生什么。将配置更改保存到git/svn/etc,将更改推送到服务器框并覆盖旧文件。完成。当您进行更改时,数据库的接触会更少,您的配置可以置于版本控制之下,并且您的应用程序现在直接与它使用的配置(这是有意义的)耦合在一起。对于中/大型应用程序或使用您无法控制的预构建组件/框架的应用程序,这一点更有价值,而对于小规模应用程序则是如此。但是,如果在数据库中存储配置随着应用程序的增长和部署管道的复杂化而变得更加麻烦,那么它在所有方面都能发挥作用。