JBoss Drools 能否用于为批量销售交易分配信用？
我参与的项目经常使用 SQL 来访问数据仓库并根据某些规则进一步处理数字。这些规则目前是通过存储过程或类似的东西来实现的。
我没有使用过 Drools，也没有接触过它。
我特别感兴趣的是是否可以使用它来为批量销售交易分配信用。
如果有这种用法的示例，请告诉我。
谢谢。
I am involved in projects where we frequently use SQL to hit a data warehouse and further crunch the numbers depending on certain rules. These rules are currently implemented via stored procedures or something similar.
I have not used Drools or been exposed to it.
I am particularly interested in if it is possible to use it to assign credit for sales transactions, in mass.
If there are examples of this usage, please let me know.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Drools 是一个 Rete 规则引擎。我不明白它与持久数据的批量更新有什么关系。
它可以容纳确定何时分配信用是正确的规则，但它不是执行更新的工具。那是数据库问题。
它不是执行这些规则的唯一选择。您还可以选择使用在插入/更新时执行的数据库触发器来执行此操作。
更新：Drools 和存储过程是互斥的。一个是服务器端技术，另一个在数据库中运行。您必须决定在哪里执行业务逻辑。
存储过程的问题在于，它将您与数据库供应商联系在一起，并且它在数据库事件上执行，例如在插入或更新之前或之后。它不会知道您的业务事件，例如“规则告诉我此人有资格获得信用”，除非您将其嵌入到存储的过程代码中。
如果你这样做了，你就不需要流口水了。两者是互斥的或者是多余的。
Drools is a Rete rules engine. I don't see what it has to do with mass updates of persistent data.
It can house the rules that determine when assigning that credit is correct, but it would not be the tool for performing the update. That's a database issue.
It's not the only choice for executing those rules. You might also choose to do it using database triggers that are executed ON INSERT/UPDATE.
UPDATE: Drools and stored procs are mutually exclusive. One's a server side technology, the other runs in the database. You have to decide where you what to execute your business logic.
The problem with a stored proc is that it ties you to that database vendor and it executes on database events, like BEFORE or AFTER INSERT or UPDATE. It won't know about your business events, such as "the rules tell me that this individual qualifies for a credit", unless you embed it in stored proc code.
If you do that, you don't need Drools. The two are mutually exclusive or redundant.
Drools 经常用于分配信用，因此我相信您会发现在那里编写信用规则非常有用（在版本之间更改它们，甚至让信用专家使用 Guvnor 自己编写它们）。
至于数据库中的实施：
在业务层（服务器端）保存销售记录之前应用信用规则。如果您有一个 3 层架构（客户端 - java 服务器 - 数据库），这应该很容易。您可能想要使用
StatelessSession（但仅实例化您的KnowlegdeBase一次）。alreadyCreditCheckedfalse标记销售记录，向单独的进程发送信号，该进程提取尚未检查的记录并进行检查。Drools is used a lot to assign credit, so I believe you'll find it very useful to write your credit rules there (to change them between releases or even let the credit experts write them themselves with Guvnor).
As for implementation in your database:
Either apply the credit rules before you save the sales record in your business layer (server-side). If you got a 3 tier architecture (client - java server - database), this should be easy enough. You probably want to use a
StatelessSession(but only instantiate yourKnowlegdeBaseonce).Either flag the sales record with boolean
alreadyCreditCheckedfalse, send a signal to a separate process, which extracts those not yet checked and checks them.