是否有任何指导方针/最佳做法可用于决定应在数据库中存储哪种类型的数据？
例如，可以使用数据库来存储
我见过使用数据库存储这些应用程序的应用程序。这可以接受吗？这种设计的优点和缺点是什么？
答案 0 :(得分：6)
要回答这个问题，我们必须了解数据库存储提供的平面文件存储空间不可用。
如果这些是您的数据的最终用途，最好将它们存储在数据库中。
答案 1 :(得分：4)
申请日志
虽然将数据库中的数据限制在特定的时间范围内（例如，转储/归档/压缩到属于3个月以上的所有内容）通常是一个好主意，但将数据存储在数据库中可以非常快速简便地进行分析的数据。需要查看特定用户的操作？ “ SELECT * FROM logs WHERE User ='bla'”。需要找出系统在特定时间崩溃的原因？ “ SELECT * FROM logs WHERE Timestamp BETWEEN failure - 1小时AND failure + 5 minutes ”。
配置详细信息（如服务器IP地址等）
这取决于配置细节。有些是，有些没有。对于在多个客户端（例如网站）上运行且可能经常更改的应用程序（即用户设置）有效的所有内容都应该放在数据库中。对于或多或少的静态选项，我更喜欢使用配置文件。
系统信息（例如，shell脚本的名称，批处理作业的计划信息，批处理作业状态等）
我猜这与配置细节几乎相同。如果它改变：数据库。如果它是静态的：配置文件。 Shell脚本通常是静态的。计划信息和状态将随着时间的推移而变化。
答案 2 :(得分：3)
我们已经在最后几个项目中存储了数据库中的所有内容，这在从开发到生产的过程中确实很有用，因为在应用程序本身中配置很少。
登录数据库非常有用（例如Log4j），因为它允许广泛访问测试人员和分析人员的日志。
我想这取决于你的情况。存储在数据库中的所有内容都会为系统增加一定程度的复杂性。读取文件比访问数据库以从代码获取相同信息更容易。一个可能的规则，如果拇指是说系统越大，它应该存储在数据库中。
答案 3 :(得分：2)
一个小问题：99％的时间将配置存储在数据库中是一个糟糕的主意。配置太重要了，不能丢失到南方的数据库连接：它需要100％防弹。
答案 4 :(得分：2)
RE：配置数据 将配置数据保存在数据库中以便更容易编辑它并跟踪更改，然后将其转发到配置文件以供实际程序读取可能是个好主意。
为什么apache必须知道有关数据库信息的任何信息才能进入其配置？
数据库关闭时，为什么FTP服务器会停止工作？
RE：应用程序日志
如前所述，数据库可以使日志分析变得更加容易，但我建议您考虑日志到文件和批量导入的模式。
效果问题
数据库非常适合将随机数据输出并放入数据的随机位。日志数据主要不是随机写入的，而是连续的数据流，非常适合将文件放在另一行中。在编写数据时，您无法击败平面文件的性能。也没有很多东西可以打破平面文件。这也让数据库专注于做实际的业务工作。
然后，您可以从文件中收集所有记录的数据，解析它，执行任何所需的后处理（如从IP地址查找主机名）并将其放入数据库表中。您可以在必要时经常这样做。对于我的网站，我真的不需要能够查看访问者统计信息从一分钟到另一分钟的变化，所以我在晚上运行日志批处理。如果您需要最新信息，您也可以每60秒运行批量导入，但这仍然比为每个实际业务事务执行一个额外的INSERT语句更好（当然，取决于您记录的数量）。 / p>
<强> 安全
如果数据库是您的日志引擎，如何记录失败的数据库连接？
如何在崩溃涉及的事件期间数据库早期崩溃时，如何调查系统崩溃的原因？
所以我认为您应该考虑何时需要数据库中的日志数据以及为什么需要它。
答案 5 :(得分：1)
尚未提及的一件事是，如果您在数据库中推送应用程序配置等内容，则无法轻松将其置于版本控制之下。
例如，某些CMS喜欢将HTML模板推送到数据库而不是文件中。我个人认为这是糟糕的设计。您无法对模板所做的任何更改进行版本更糟糕，更糟糕的是，您所做的只是复制和放大。从真正的文本编辑器粘贴到浏览器中的wimpy文本编辑器中。
底线？问问自己这是否是你想要版本化的东西。如果是，请将其保留在数据库之外。如果不是，请确保将其放入数据库中。
答案 6 :(得分：0)
专注于易用性和维护。我存储在数据库中的唯一日志是由错误输出的触发器放在那里，因为这是最简单的。但是对于其他一切，搜索和解析文本日志更快更容易。如果您的应用程序崩溃，查看文本配置文件比查看数据库更容易，尤其适用于新维护者。对于新人来说，在app.properties目录中查看config/文件要比查看数据库中的表格要容易得多。
此外，如果配置文件是文本文件，则可以更轻松地将配置文件存储在源代码管理中，而不是存储在数据库中。相信我，这非常重要。您不想调试丢失导致错误的配置文件设置的应用程序。如果您遇到数据库崩溃或损坏，您可能会丢失日志和配置设置，这可能导致无法找到问题。
答案 7 :(得分：0)
如果您正在开发一个小型的静态网站，那么我会同意已经提出的大多数观点。但是，如果您有一个允许用户通过生产站点添加内容的网站，我会认为在数据库中放置配置会使部署管道变得复杂，从而使其远离数据库更为可取。
如果您尝试将更新从开发推送到生产，客户端正在将内容推送到生产环境，并且您的配置和内容都在同一个数据库中，那么您只需要定位具有要覆盖的配置数据的表。这个“可以”对您来说是一项微不足道的额外工作，但这取决于应用程序的规模以及您是否正在使用别人的代码。考虑drupal网站。如果用户正在添加内容然后进行部署，则需要将特定数据库表作为目标进行覆盖。由于drupal有几个表（没有一个表的名字配置），你需要做一些研究来弄清楚什么可以被覆盖，哪些不可以。现在，如果drupal的数据库布局发生了变化，会发生什么？部署管道可能会中断，这对您来说是更多的额外工作。添加新插件会发生什么？更多配置表，因此需要更改部署脚本。为你做更多的工作。如果您最终继续从该项目开始，您将需要与新开发人员分享信息，以解释您对这些部署问题所做的工作。为你做更多的工作。
考虑如果配置不在数据库中但在应用程序目录结构中会发生什么。将配置更改保存到git / svn / etc，将更改推送到服务器框并覆盖旧文件。 DONE。当您推出更改时，数据库将被触及较少，您的配置可以置于版本控制之下，并且您的应用程序现在直接与其使用的配置相关联（这是有意义的）。对于中等/大规模应用程序或使用您无法控制的预构建组件/框架的应用程序而言，这对于小规模应用程序更有价值。但是，它适用于所有规模，因为随着应用程序的增长和部署管道变得复杂，数据库中的存储配置变得更加麻烦。