我必须扩展使用 Oracle 11g 处理法律案件的 .Net 4/C# 案件管理应用程序。
我的预算很少，我在 Oracle 方面的经验和一个非常初级的 C# 开发人员可以完成这项工作。附加模块将由不超过 20 人在 Intranet 上使用。
现有的规则一般是这样的：
- 为了完成一个操作，表中必须存在属性 a、属性 b、属性 c，并且与必须验证新插入的表具有明确定义的关系
- 对于法律案件，新的业务规则更像是“一切都是例外”，因为其他表中的数据条目可能会或可能不会影响基于未知条件的未来交易的结果，因此更正式地重述
现有应用程序使用 Microsoft Workflow 来实施业务规则。这已被证明是笨拙的，对我们来说几乎无法使用。Drools 及其商业等价物同样复杂，无法实现让管理者了解其业务逻辑的目标。
- 如果用户无需阅读 C# 注释或代码就可以在报告中看到业务逻辑，那将是一个好处。
- 无需关闭 Web 应用程序即可快速添加或禁用逻辑
- 鉴于我们的预算和技能有限，实施起来相当容易
这让我想起了将业务逻辑作为一系列决策表保存在数据库中的老式想法。这仍然是这样做的，还是认为在应用程序中保留业务逻辑的效率明显更好？
编辑：工作流作为服务实现。我的理解是它针对的是长时间运行的工作流程。在我们的例子中，用户按下保存按钮，工作流运行。我们的问题是
- 在我们的机器上开发非常缓慢、冻结、崩溃
- 难以调试
- 工作流管理器有时会无缘无故地抛出几个小时的错误
- 触摸一个工作流，你必须更改其他 14 个文件
- 应用程序对用户来说很慢，我们已经将其中的一部分追溯到工作流程。
在数据库中进行验证开始看起来不错，因为验证全部基于数据库中的数据。
@catcall 有 10 或 12 名律师不使用该应用程序，但有 8 或 10 名管理员进行数据输入。
我们刚刚完成桌面升级，但老板认为程序员承包商的设备不应该比员工更好。因此，具有 4 个内核和 3 GB 内存的 Windows XP 是我们能做的最好的。我将调查是否有业务逻辑类型的任何分类。其中一些可以在应用程序中更有效地完成。其他类型可能更容易在数据库端更改和配置。
当您谈论法律应用时，“人”是一个模糊的术语。支持 20 名律师与支持 1 名律师、4 名律师助理和 15 名员工有很大不同。
这就是原因之一。在案例管理中，某些类型的事情只是确定性的。回复的时间、提交的截止日期，诸如此类。但管理规则是由律师为律师制定的。开发案例管理软件的公司都有律师来阅读程序规则（随着时间的推移而变化）并验证他们的软件是否符合规则。
其中一些有很多律师。
其他种类的事物受奇思妙想的支配。例如，一些案例管理包允许用户“模板化”他们的任务。在日历上输入诸如“证词”之类的内容也可能会记录一系列为准备证词而必须完成的早期任务。在多个不兼容的截止日期的压力下，任务链的某些部分会被丢弃或被忽视。
现在，（终于）回答你的问题。. .
数据库中的决策表是一个可行的解决方案。事实上，无论是存储在 Oracle 中还是应用程序代码中，决策表都构成了一个数据库。在应用程序代码中存储决策表有明显的折衷。
但是数据库中的决策表对您来说可能不是一个可行的解决方案。如果我理解正确的话，您遇到的问题是您认为您可能需要将体系结构简化为决策表以消除（或至少大大减少）Microsoft Workflow 的使用。只有你们两个人和最少的预算，充其量也很难成功。
我可以建议两件事。