规则引擎是否适合根据一组规则验证数据？
我试图设计一个应用程序，允许用户根据不同的配置创建订阅——表达他们在满足这些条件时接收警报的兴趣。
在评估实现相同功能的选项时，我考虑使用Drools等通用规则引擎来实现相同功能。从高层来看，这似乎是一个自然的适合这个问题的方法。但深入挖掘并仔细思考一下，我怀疑业务规则引擎是否是正确的使用方式。
我认为规则引擎可以根据预定义的条件选择规则，并将规则应用于该数据以产生结果。然而，我的要求是从数据（生成的事件）开始，并基于用户配置的规则（订阅）进行标识，以标识满足正在处理的事件的所有规则（订阅）。以便可以生成警报到所有这些订阅服务器。
举个例子，当亚马逊的产品在接下来的7天内跌破10美元时，用户的假设订阅可能会被提醒。另一个用户会创建一个订阅，当亚马逊的产品在未来30天内跌至15美元以下时，会收到通知，并为主要会员提供免费的一日送货服务。
经过一番思考，我决定将规则/订阅存储在关系数据库中，并通过查询数据库来确定哪些订阅将触发事件警报。
我选择这种方法的主要原因是数量，因为我使用的规则/订阅的数量将约为1000条复杂规则，并且随着更多用户添加到系统中，规则/订阅的数量将呈指数增长。使用查询方法，我可以触发一次查询，一次性验证所有规则，而规则引擎方法则需要我根据配置的规则数进行多次验证。
虽然我知道我的数据库方法会起作用（可能效率不高），但我只是想了解规则引擎是否可以用于这些目的，并且能够随着规则数量的增加而扩展。（性能是最重要的，因为每分钟要处理的事件数约为1000）
如果规则引擎不是处理它的正确方法，我还有什么其他选择可以探索，而不是编写我自己的实现。
共有1个答案
你弄错了。标准规则引擎根据数据选择要执行的规则。规则约束将使用插入规则引擎的数据进行评估。如果规则中的所有约束与数据匹配，则执行该规则。我建议你试试口水。
-
我正在从事这个项目，我的角色是开发使用标准健康保险xml的服务。服务必须在不同的xml字段上进行验证，这涉及将xml数据与数据库表中的数据进行比较。目前，我们假设所有保险公司的验证保持不变。但我怀疑它会保持不变，并且每家公司可能有不同的验证要求。在这种情况下，使用Drools规则引擎并为每家公司开发drl文件并使用规则引擎进行xml验证是个好主意吗
-
我正在为我的项目评估一个规则引擎。该项目将基于hadoop。我用DROOLS做了一些POC。基本上，我使用DROOL在映射器一侧。基于此，以下是我的观察和质疑。 1） a）我使用DROOLS在300万对象上启动了规则（大约需要17秒）b）我使用简单的Java对象（大约需要17秒）为没有DROOLS的300万对象使用了与DRL文件中相同的if/else循环逻辑。b大约比a快100倍。这是正常行为吗？
-
验证规则的定义通常有两种方式，如果你使用了验证器的话，通常通过rule属性定义验证规则，而如果使用的是独立验证的话，则是通过rule方法进行定义。 属性定义 属性定义方式仅限于验证器，通常类似于下面的方式： <?php namespace app\index\validate; use think\Validate; class User extends Validate { prot
-
我正在向drools规则引擎插入数据，但我无法理解它是如何处理插入的数据的。插入数据的代码是：
-
本文向大家介绍laravel 数据验证规则详解，包括了laravel 数据验证规则详解的使用技巧和注意事项，需要的朋友参考一下 如下所示： 简单例子 特殊例子 以上这篇laravel 数据验证规则详解就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持呐喊教程。
-
我们已经使用Drools引擎几年了，但是我们的数据已经增长了，我们需要找到一个新的分布式解决方案来处理大量数据。我们有复杂的规则，可以查看几天的数据，这就是为什么Drools非常适合我们，因为我们的内存中只有数据。 你对类似于流口水但分布式/可扩展的东西有什么建议吗？ 我确实对这件事进行了研究，但我找不到任何符合我们要求的东西。 谢谢