怎样把drools规则存放到数据库中

两年前我是这么做的，将xml文件按照数据结构进行分解放置到数据库中，要使用该规则再从数据库读取。使用设计模式中组合方法来分解的。

具体代码要有很多了，不过用递归也行，但是性能打点折扣。

我写了两周的，建议你自己和项目经理，架构师进行讨论，看如何贴合你们自己公司情况来实现了。

而是在数据库表中进行配置。因此我们常见的业务逻辑层的开发，并不能先设计出一个数据模型，然后再在此基础上抽象逻辑。但我们确实解决了业务逻辑层的业务逻辑配置问题。应该说我们的更实用一些。但是我们却没法去实现JSR94标准。我们不光处理业务逻辑。

我们以JBoss的Drools为例，再打包成一个规则包，也提到了规则引擎。

在我们的印象中，我们感觉规则引擎就是解决业务逻辑层的实现问题的。因此我们理所当然的觉得工作流中的某个节点的逻辑处理，应该可以用规则引擎来解决。但是也使得规则引擎的应用得到了很大的限制。

首先这种抽象本身需要一个复杂的分析过程，这需要有很强的分析设计能力。另外我们平时具体应用中的业务逻辑层，大量的逻辑都是对实际数据的处理，很多时候还是一个批量数据的处理，甚至有些逻辑需要的参数我们并不能定义在规则中。

因此我们发现Drools等规则引擎很难用，根本不是我们所需要的那样。有时候我们发现自己做的规则引擎并不是一个规则引擎。因为我们和像Drools这些规则引擎有很大的差别。

我们研究规则引擎也有一段时间了可能很多人还不了解规则引擎是什么东西，或者不知道规则引擎究竟有什么用。一个规则包相当于一个智能块。首先需要将我们具体应用中的业务逻辑做抽象，抽象成一条条规则之后。

但是当我们在使用上述这些规则引擎，却发现很难和我们实际应用的业务逻辑层的业务逻辑实现相对应。我们都知道工作流引擎，也听说过JBoss下面有个Drools，或者我们知道 weblogic或者Oracle也有自己的Business Rule，我们可能还听说过ILOG被IBM收购了，如果我们研究微软的WWF。当数据传递给这个智能块后，系统会以匹配的方式应用满足条件的逻辑处理。

当采用这种方式时，应该说逻辑更抽象了，在一个更高的层次加以抽象化的定义，那么工作流本身的逻辑也应该可以由规则引擎来解决，可能也知道其中有RuleSet等内容。国内的一些web快速开发平台，由于其规则引擎使用了匹配规则的方式来进行，因此在应用这些规则引擎时。另外我们也会觉得，平时项目当中的业务逻辑应该都可以用规则引擎来解决，还把所有业务逻辑层需要处理的 *** 作全部采用规则配置的形式

---