我正在围绕很多分层数据编写应用程序。目前，层次结构是固定的，但将来可能会将新项目添加到层次结构中。 （请让他们离开）
我当前的应用程序和数据库设计相当通用，除了为从每个节点的特定数据库检索外部数据而编写的验证和查找函数之外，没有处理层次结构中特定节点的任何内容。从设计的角度来看，这让我很高兴，但是我很紧张整个应用程序依赖于数据库中的少数记录。我也很沮丧，我必须使用数据库触发器而不是外键约束强制执行数据完整性的某些方面（例如，层次结构中的几个不同节点有自己的专有ID，我将它们存储在一个列中，当与节点ID结合使用时，可以用来定位外来数据）。
我开始怀疑将这些已知节点硬编码到系统中是否合适，以便它更“安全”并且不那么通用。
如何知道什么时候应该硬编码，何时应该是配置项？现在只是对清晰度/安全性的成本效益分析与之后的工作量减少，或者我错过了一些我应该用来确定这是否合适的度量标准。
我正在采取的保护这些有价值配置的步骤是添加阻止更新/删除的触发器。此应用程序使用的数据库用户只能通过存储过程操作数据。我还能做什么？
答案 0 :(得分：4)
你走在正确的轨道上。有一点成本效益。其他考虑因素是维护和复杂性。
复杂性：任何动态层次结构都比静态层次结构更复杂。这涉及更多编码和测试，因为还有更多可能的失败案例。如果您目前不需要更新层次结构，那么复杂性可能不值得吗？我们经常过度优化复杂性，因为我们期待在遥远的未来发生变化。这导致我进行维护......
维护：考虑层次结构中的更改用例。什么外部事件会触发维护层次结构的需要，谁将确保这种情况发生？这种变化是否需要备份，审核，版本化，批准，上演等？源控制系统提供了许多这些功能。
因此，例如，如果层次结构代表公司的业务单位，并且您的用例是远期公司合并，那么假设HR系统中的静态层次结构可以由程序员更新是非常合理的。事实上，在合并中，整个系统可能会被淘汰（！）。
另一方面，如果层次结构是产品目录，我们都知道营销人员会定期重新编排和优化这些数据。此外，如果他们被告知将有一个为期2周的软件项目来重新编码，每季度测试和重新部署目录，我很确定他们不会对设计感到满意。因此，动态的，DB驱动的模型是有意义的。