sql – 在数据库级别应用业务规则

2023年4月16日 287次阅读

我正在开展一个项目,我们需要为存储在数据库中的大量人员确定某些类型的状态.确定这些状态的业务规则相当复杂,可能会发生变化.

例如,

if a person is part of group X 
and (if they have attribute O) has either attribute P or attribute Q, 
or (if they don't have attribute O) has attribute P but not Q,
and don't have attribute R, 
and aren't part of group Y (unless they also are part of group Z), 
then status A is true.

乘以几十个状态,可能还有数百个组和属性.人员,组和属性都在数据库中.

虽然这将由Java应用程序使用,但我们还希望能够直接针对数据库运行报告,因此最好是在数据级别提供计算状态集.

那么,我们当前的设计计划是为每个人创建一个包含一组布尔标志(hasStatusA？hasStatusB？hasStatusC？)的表或视图.这样,如果我想查询具有状态C的每个人,我不必知道计算状态C的所有规则;我只是检查一下旗帜.

(注意,在现实生活中,标志将具有更有意义的名称：isEligibleForReview？,isPastDueForReview？等).

那么a)这是一种合理的方法,并且b)如果是这样,那么计算这些标志的最佳方法是什么？

我们正在考虑计算标志的一些选项：

>使标志集成为视图,并使用SQL或PL-SQL(这是Oracle DB)实时计算基础数据中的标志值.这样,值总是准确的,但性能可能会受到影响,并且规则必须由开发人员维护.
>使标志集由静态数据组成,并使用某种类型的规则引擎在基础数据发生变化时使这些标志保持最新.这样可以更容易地维护规则,但是在给定的时间点,标志可能是不准确的. (如果我们采用这种方法,是否有一个规则引擎可以通过这种方式轻松操作数据库中的数据？)

最佳答案 在这种情况下,我建议应用Ward Cunningham的问题 – 问自己“什么是最简单的可能有用的东西？”.

在这种情况下,最简单的事情可能是提出一个视图,该视图查看数据是否存在,并进行计算和计算以生成您关心的所有字段.现在,加载您的数据库并试用它.它足够快吗？如果是这样,那么好 – 你做了最简单的事情而且效果很好.如果它不够快,那么好 – 第一次尝试不起作用,但是您已经在视图代码中映射了规则.现在,您可以继续尝试“最简单的事情”的下一次迭代 – 也许您编写一个后台任务来监视插入和更新,然后跳转来重新计算标志.如果这工作,罚款和花花公子.如果没有,请转到下一个迭代……依此类推.

分享和享受.

点赞