数据驱动的业务规则。

发布于 11-27 04:59 字数 593 浏览 1 评论 0原文

我正在使用 SQL SERVER 2005。

我有一个表现

table1(ID,col1,col2,col3,col4);

在我有一个业务逻辑,例如:

If col1 >= 126 and col2 > 1 then col3 = 0
if col1 >=126 and col2 < 1 then col3 = col1+col4

现在我想做的是将所有这些规则存储在数据库中并使其成为数据驱动的。这样做的原因是为了给最终用户更大的灵活性。如果明天业务规则发生变化,最终用户可以通过 GUI 灵活地进行更改。例如。如果明天企业想要将比较值从 126 更改为 200,他们应该能够通过界面进行更改。我尽可能提供灵活性,例如更改列的能力,就像业务应该能够更改规则一样,因此他们可以将新规则更改为 col2,而不是 col1。如果可能的话,他们也可以更改运算符,而不是 >=,他们可以将其更改为 <=。

我想将其更改为更多数据驱动,因此当表中的值发生更改时,我们不需要更改代码。

可以在数据库中做这件事吗?有人可以建议支持该业务规则的数据模型是数据驱动的吗?

I am using SQL SERVER 2005.

I have a table

table1(ID,col1,col2,col3,col4);

Now I have a business logic like:

If col1 >= 126 and col2 > 1 then col3 = 0
if col1 >=126 and col2 < 1 then col3 = col1+col4

Now what I am trying to do is store all these rules in database and make it data driven. THe reason for that is to give the end user more flexibility. If tomorrow the business rules changes, end user have the flexibility to change it through the GUI. For eg. if tomorrow the business wants to change the comparision value from 126 to 200 they should be able to change that through the interface. As far as possible I am trying to give flexibility like ability to change columns too like business should able to change the rule so instead of col1 they can change new rules to col2. and if possible they can also have the ability to change the operators too instead of >= they can change it to <=.

I want to change it more data driven so when the value is changes in the table we don't need to change the code.

Is it possible to do this thing in database? Can someone suggest the data model that supports this business rules to be data driven?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

爱*していゐ2024-12-04 04:59:57

不要将代码存储在数据库中。数据库是用来存储数据的。代码是为了代码。

请参阅内部平台效应反模式。

Maaaybe 您可以将 126 和 200 之类的值存储在数据库中,但我会将它们放在配置文件中。但是,一旦用户需要如此多的灵活性,以至于您必须为他们设计数据驱动的业务规则引擎,那么您就完全是在重新发明轮子。

在以下方面这对您来说将是一场噩梦:

  • 安全风险,因为用户指定的表达式为代码注入攻击创造了机会。
  • 可测试性,因为如果您的规则引擎包含构造性语法,您将无法预测操作范围。
  • 性能,因为用户会添加大量任意表达式和排序条件,这些表达式和排序条件在您的服务器上运行之前不会经过性能测试和优化。
  • 维护,因为用户会习惯于他们可以做任何事情,但他们可以想象报告远比您编写业务规则来处理的复杂。

更新:有一些业务规则平台,例如 Drools,但这些平台应该有自己的语言来执行业务规则。 SQL 并不是执行此操作的最佳语言。

Do not store code in the database. The database is for data. Code is for code.

See the Inner-Platform Effect antipattern.

Maaaybe you could store values like your 126 and 200 in the database, but I'd put them in a config file. But once the users want so much flexibility that you have to design a data-driven business rules engine for them, you're totally reinventing the wheel.

It'll be a nightmare for you in the following ways:

  • Security risks, because user-specified expressions creates an opening for code injection attacks.
  • Testability, because you can't predict the ranges of operations if your rules engine includes a constructive grammar.
  • Performance, because users will add tons of arbitrary expressions and sorting criteria that won't go through performance testing and optimization before running on your server.
  • Maintenance, because users will become accustomed to the idea that they can do anything, but they can imagine reports far more complex than you can code your business rules to handle.

Update: there are business rules platforms such as Drools, but these should have their own language for executing business rules. SQL is not the best language to do that.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文