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

Question

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

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

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

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

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

Answer 1

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

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

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

例如，如果层次结构代表公司的业务部门，并且您的用例是未来的公司合并，那么假设 HR 系统中的静态层次结构可以由程序员更新是非常合理的.事实上，在合并中，整个系统可能会被抛弃（！）。

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