在我的应用程序中，我有一组要执行的作业。每个工作都经历“未开始”，“开始”，“完成”，“失败”等状态。每个工作都有一系列先决条件和后置条件。在满足前提条件之前，作业无法启动，如果不满足后置条件，则应将其标记为失败。
例如，假设作业将文本文件导入数据库。前提条件是检查源文件是否存在，后置条件是检查数据库中是否存在数据。
除了这些前后条件之外，有时候工作也依赖于其他工作来完成。创建作业表并为作业创建依赖表很容易，但是实际上可以使这些前后验证检查在数据库中可配置（这样如果这些条件发生变化，则不需要进行代码更改或新增条件）？即使有可能，这样做也是个好主意吗？
需要使此模型具有通用性，以便其他应用程序也可以使用它，即使要执行的验证检查对于其他应用程序完全不同。
答案 0 :(得分：1)
我认为你冒着尝试过多驱动器的风险。通过尝试表格驱动所有验证前和验证后的条件，您将面临着尝试在数据中编写代码的危险。
我已经构建了一些相当复杂的作业调度应用程序。特别值得关注的是每日ETL过程，它基于平面文件源加载了数十个SQL表。
现有系统使用线性过程，程序员必须手动计算出表间依赖关系并按给定顺序运行表加载。这样做的问题是，如果任何进程失败，其余的工作必须等待，直到问题得到解决。
我构建了一个新系统，该系统具有表驱动的元数据，指出了直接的表间依赖关系。换句话说，表A具有表B和C的FK。而不是手动跟踪所有的相互依赖性，而是仅跟踪直接的相互依赖性。然后调度程序只需要查看哪些负载已完成以及哪些负载没有完成。任何没有不完整依赖关系的挂起负载都可以启动。
我认为你应该建立类似的系统。使用关注点分离。不要表驱动依赖项，而应该只驱动存在哪些依赖项。您可以在调度表中跟踪哪些依赖项已通过，哪些已失败。数据库不需要知道如何进行这些测试。让代码担心依赖关系究竟是什么以及如何测试它们是通过还是失败。这就是你的工作安排员需要知道的全部内容。避免创建一种源代码位于数据库中的脚本语言。
答案 1 :(得分：1)
考虑将您的应用程序与规则引擎（也称为业务规则）集成。这个想法是在代码之外定义逻辑并存储在表或文件中。规则引擎读取规则并解释。
这些软件很快就会变得复杂。大多数情况下，它们是商业软件包，但存在一些免费和开源框架。我没有使用任何免费套餐。一般来说，我建议考虑退出代码，而不是从头开始构建规则引擎。
Martin Fowler的简介： http://martinfowler.com/bliki/RulesEngine.html
一篇含有更多实质内容的文章： http://www.infoq.com/articles/Rule-Engines
要在“规则引擎”或“工作流引擎”上找到实际代码，Google并添加您的编程语言的名称（“Java”，“C＃”或什么不是）。