应该将核心应用程序配置存储在数据库中，如果有的话应该采取什么措施来保护它们？

Question

我正在围绕很多分层数据编写应用程序。目前，层次结构是固定的，但未来可能会将新项目添加到层次结构中。 （请让他们离开）

我目前的应用程序和数据库设计是相当通用的，没有任何处理层次结构中的特定节点的硬编码，除了验证和查找函数写入从每个节点的特定数据库检索外部数据。从设计的角度来看，这让我感到满意，但我很紧张地认识到整个应用程序依赖于数据库中的一些记录。我也很沮丧，我必须用数据库触发器而不是外键约束强制执行数据完整性的某些方面（例如，层次结构中的几个不同节点都有自己的专有ID，并将它们存储在单个列中，当加上节点ID可以用来定位外部数据）。

我开始怀疑将这些已知节点简单硬编码到系统中是否合适，以便它更“安全”并且通用性更低。

如何知道什么时候应该硬编码，什么时候应该是配置项？这是否仅仅是对清晰度/安全性的成本效益分析，而不是稍后的工作量较少，还是我缺少一些我应该用来确定这是否合适的指标。

我正在采取的保护这些有价值配置的步骤是添加防止更新/删除的触发器。此应用程序使用的数据库用户只能通过存储过程操作数据。我还可以做些什么？

Answer 1

你是在正确的轨道上。有一点成本效益。其他考虑因素是维护和复杂性。

复杂性：任何动态层次结构都将比静态层次结构更复杂。这涉及更多的编码和测试，因为还有更多可能的失败案例。如果您目前没有需要更新层次结构，那么复杂性可能不值得吗？我们经常过度优化复杂性，因为我们预计未来会发生变化。这导致我进行维护...

维护：考虑您的层次结构变化的用例。什么样的外部事件会引发需要维护层次结构和谁来确保发生这种情况？这种改变是否需要备份，审计，版本控制，批准，上演等？源代码管理系统提供了许多这些功能。因此，例如，如果层次结构代表公司的业务单位，并且您的用例是未来的公司合并，那么假设HR系统中的静态层次结构可以通过以下方式进行更新将是非常合理的：程序员。事实上，在合并中，整个系统可能会被抛出（！）。另一方面，如果层次结构是产品目录，我们都知道市场营销人员会定期对这些数据进行重新规划和细化。此外，如果他们被告知将有一个为期两周的软件项目来重新编码，测试和重新部署每个季度的目录，我很确定他们不会对设计感到满意。因此，动态的DB驱动模型是有意义的。