核心应用程序配置是否应该存储在数据库中？如果是，应该采取什么措施来保护它们？
我正在围绕大量分层数据编写一个应用程序。目前层次结构是固定的，但将来可能会添加新项目到层次结构中。 （请让它们成为叶子）
我当前的应用程序和数据库设计相当通用，除了为从每个节点的特定数据库检索外部数据而编写的验证和查找函数之外，没有对层次结构中的特定节点进行硬编码。从设计的角度来看，这让我很高兴，但是当我意识到整个应用程序依赖于数据库中的少量记录时，我感到很紧张。我还感到沮丧的是，我必须使用数据库触发器而不是外键约束来强制执行数据完整性的某些方面（一个示例是层次结构中的几个不同节点都有自己的专有 ID，我将它们存储在单个列中，当与节点 ID 结合时可用于定位外部数据）。
我开始怀疑将这些已知节点简单地硬编码到系统中是否合适，以便它更加“类型安全”并且不那么通用。
人们如何知道什么时候应该对某些东西进行硬编码，什么时候应该将其作为配置项？这只是现在的清晰度/安全性与以后的工作量减少的成本效益分析，还是我错过了一些我应该用来确定这是否合适的指标。
我为保护这些有价值的配置而采取的步骤是添加防止更新/删除的触发器。此应用程序使用的数据库用户只能通过存储过程操作数据。我还能做什么？
I'm writing an application around a lot of hierarchical data. Currently the hierarchy is fixed, but it's likely that new items will be added to the hierarchy in the future. (please let them be leaves)
My current application and database design is fairly generic and nothing dealing with specific nodes in the hierarchy is hardcoded, with the exception of validation and lookup functions written to retrieve external data from each node's particular database. This pleases me from a design point of view, but I'm nervous at the realization that the entire application rests on a handful of records in the database. I'm also frustrated that I have to enforce certain aspects of data integrity with database triggers rather than by foreign key constraints (an example is where several different nodes in the hierarchy have their own proprietary IDs and I store them in a single column which, when coupled with the node ID can be used to locate the foreign data).
I'm starting to wonder whether it may have been appropriate to simply hardcoded these known nodes into the system so that it would be more "type safe" and less generic.
How does one know when something should be hardcoded, and when it should be a configuration item? Is it just a cost-benefit analysis of clarity/safety now vs less work later, or am I missing some metric I should be using to determine whether or not this is appropriate.
The steps I'm taking to protect these valuable configurations are to add triggers that prevent updates/deletes. The database user that this application uses will only have the ability to manipulate data through stored procedures. What else can I do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你走在正确的轨道上。有一点成本效益。其他考虑因素是维护和复杂性。
复杂性：任何动态层次结构都会比静态层次结构更加复杂。这涉及更多的编码和测试，因为可能的失败情况更多。如果您当前不需要更新层次结构，也许复杂性不值得？我们经常对复杂性进行过度优化，因为我们预计遥远的未来会发生变化。这导致我进行维护...
维护：考虑层次结构中更改的用例。什么外部事件会触发维护层次结构的需要，谁将是确保这种情况发生的人？此更改是否需要备份、审核、版本控制、批准、暂存等？源代码控制系统提供了很多这样的功能。
例如，如果层次结构代表公司的业务部门，并且您的用例是遥远未来的公司合并，那么假设人力资源系统中的静态层次结构可以由程序员更新是非常合理的。事实上，在合并中，整个系统可能会被抛弃（！）。
另一方面，如果层次结构是产品目录，我们都知道营销人员会定期重新组织和细化这些数据。此外，如果他们被告知每个季度将有一个为期 2 周的软件项目来重新编码、测试和重新部署目录，我很确定他们不会对设计感到满意。因此，动态的、数据库驱动的模型是有意义的。
You are on the right track. There is a bit of cost-benefit. The other considerations are maintenance and complexity.
Complexity: Any dynamic hierarchy is going to be more complex than a static one. This involves more coding, testing, because there are many more possible failure cases. If you do not currently have a need to update the hierarchy, perhaps the complexity is not worth it? We often over-optimize towards complexity because we are anticipating changes in the far future. Which leads me to maintenance...
Maintenance: Think of the use case for change in your hierarchy. What external event would trigger the need to maintain the hierarchy and who would be the person making sure this happens? Does this change need to be backed-up, audited, versioned, approved, staged, etc? Source control systems provide a lot of these features.
So for example, if the hierarchy represents the business units of a company, and your use case is a far future corporate merger, then it would be very reasonable to assume that a static hierarchy in an HR system could be updated by programmers. In fact, in a merger maybe the whole system could get tossed out (!).
On the other hand, if the hierarchy is a product catalog, we all know that marketing people re-ogranize and refine this data regularly. And furthermore if they are told there will be a 2 week software project to recode, test and redeploy the catalog each quarter, I am pretty sure they are not going to be happy with the design. Thus a dynamic, DB-driven model makes sense.