database - 核心应用程序配置是否应该存储在数据库中，如果是，应该如何保护它们？

Question

我正在围绕大量分层数据编写应用程序。目前层次结构是固定的，但将来可能会向层次结构中添加新项目。 (请让它们成为树叶)

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

我开始怀疑将这些已知节点简单地硬编码到系统中是否合适，这样它会更“类型安全”并且不那么通用。

如何知道什么时候应该硬编码，什么时候应该是配置项？这只是现在对清晰度/安全性的成本效益分析与以后更少的工作相比，还是我遗漏了一些我应该用来确定这是否合适的指标。

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

Answer 1

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

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

维护:考虑在您的层次结构中更改的用例。什么外部事件会触发维护层次结构的需要，谁会是确保发生这种情况的人？此更改是否需要备份、审核、版本控制、批准、暂存等？源代码控制系统提供了很多这样的功能。

因此，例如，如果层次结构代表一家公司的业务部门，而您的用例是一个遥远的 future 公司合并，那么假设 HR 系统中的静态层次结构可以由程序员更新是非常合理的.事实上，在合并中，整个系统可能会被抛弃(!)。

另一方面，如果层次结构是产品目录，我们都知道营销人员会定期重新组织和优化这些数据。此外，如果他们被告知每个季度将有一个为期 2 周的软件项目来重新编码、测试和重新部署目录，我很确定他们不会对设计感到满意。因此，动态的、数据库驱动的模型是有意义的。