数据库表结构设计

Question

业务需求描述如下：

如上图所示，定义了一组规则，有区域规则，城市规则，机房规则，数量规则，比例规则，类型规则。设置规则的时候，可以将上述规则进行组合，生成一条规则集(由上述规则并集得到)。那么这样可以编辑好多规则集，形成一个list列表。如下图所示：

那么我们定义的规则集就可以生成一组的规则集列表，当生成一个订单，用户可以填写一些规则，那么服务端根据传过来的规则，匹配规则列表中的规则，选择出一堆否和条件的规则，然后按照优先考虑不同快递公司，优先某几种规则，来进行匹配相应的规则，进行物流配送。

请问这个相关的表结构该如何设计？

PS：我的表结构设计是这样的：
条件表 规则表
1.条件表中，存放单独的规则条件，他们可以组合成一条规则集。
2.规则表中，存放组合好的规则。

当web端，选了相应的规则之后，我先将前端的规则进行拆分，从条件表中分别进行匹配，然后匹配得到各种集合，然后用SQL中的in语句，拿得到的这些集合去规则表中去匹配。

第一个问题：
总觉得这样设计效率不高？有没有更好的方案呢？？？

PS:在表结构设计中，类似这种问题叫作：java 规则引擎设计。运用场景还是蛮广泛的，比如，好多电商都有风控的场景，就是一些规则来判定他的一个订单是不是刷单，它会有很多规则，那么根据一条订单的特征，生成一组规则组合，然后用订单规则匹配规则组合，算出当前的订单有多大概率是刷单的，如果刷单概率太大，就到人工审批环节，人工确认刷单后，对相应的商家要进行封号处理。

所以，第二个问题：
特别好奇一些电商或者O2O平台的，风控规则是如何设计和实现的呢？

===============================================================================
后期的发展是这样的，需求方做了让步，不想让80%的工作量带来10%的价值，所以修改了规则匹配算法，只做最精确匹配，匹配失败就不匹配了。

Answer 1

感谢邀请。@菩提旭光
对于问题1，说说我粗鄙的一些看法，我觉得你的设计是没有问题的。
表1：规则表
表2：规则集表
表2每一条记录时表1里的规则任意组合而成
假设表2中有一天记录是规则1和规则4组成，那么我们可不可以在表2中既存表1的规则描述又存表1的id呢，形如
规则ID 规则描述
1 数量>100
2 数量>10
3 本地
4 异地
规则集ID 规则集描述 规则ID连接
1 数量>100 异地 14
2 数量>10 本地 23
当然前提是表2中规则ID连接一定要从小往大旁，这样我们在查询的时候不要用like或者in了，直接用=，效率会更高吧。当然这个也是有一定弊端的，当规则改变之后，规则ID连接也需要跟着变动了

不知道我理解有没有问题。

Answer 2

我的思路是，
rule表

(id,
rule_name,      //规则名
rule_para,      //规则参数,根据不同的规则要求放入参数 
rule_action,    //规则索要响应的方法[number,sameCity,..]
rule_type,      //规则类别 [1=>区域,2=>城市,3=>数量]
start_time      //开始时间
end_time        //结束时间
status          //是否启用 
)

rule_list 表 就是存放规则集的关联性,也可以起一个关联表，

然后可以在代码里面创建一个rule class 如果rule很多的话可以为城市规则，区域规则..分别建个class(这里的话就要将上面的rule_type存为对应class的名字)，里面对应的方法就是表内存的要响应的方法，接收的参数是规则参数，然后具体逻辑写在方法内。

我第一个想法是这样的，感觉还不够成熟，不知道这样设计怎么样。

Answer 3

这里有个疑点，如果总共有4个规则，那么服务端的规则集列表就会有 4 * 3 * 2 * 1个规则集，如果有n个规则，那么服务端的规则集列表就会有n!个规则集。排列组合，产生的数目可能很大。这样是否是合理的。

这个问题我还是没看明白，我理解的就是拼SQL语句的问题，根据规则拼SQL，然后用这条SQL去表里查，好像跟表结构设计没什么关系。

Answer 4

简单的想法
规则类型表（没什么变化的话，可以放在静态字典里面）
id 规则类型
1 数量
规则表
id 规则类型ID 规程名称
1 1 数量大于100
物流匹配规则表
id 物流ID 规则ID 优先级

查询时
通过查询规则ID in(规则ID) in 效率不高可以改成exists
统计物流ID的个数，达到最优选择，如果有优先级，可以加条件进行判断，如 异地 某个物流根本不送

想法不是很成熟，
或者物流匹配规则表 每条记录里面是多个规则的，也可以，就是优先级不好判定

![表图片][1]

Answer 5

我觉得可以使用3张表
表1. 定义规则的元数据，比如某个规则是对城市的限制，是个枚举类型，另一个规则是对机房数量的限制，是数值型，字段可以是：规则id，类型，取值范围等
表2. 定义物流商和规则的映射关系，字段可以是：物流商id，规则id，规则值
表3. 定义用户订单，描述的是用户选择的规则列表，字段可以是：订单id，规则id，规则值等，一个订单可以有多条规则对应，用订单id可以查询出所有相关的用户指定的规则。

然后程序可以通过用户订单的规则列表去第二张表里找到最匹配的物流商。

回答你，我的见解：
web端要单独展现规则集的，规则集跟订单是分离的。当订单去选择物流配送的时候，才会去匹配规则集。至于表2，感觉没必要啊，物流商和规则的匹配高一个加权的轮询策略就好了，不用单独设计表，查表的效率一般都是很慢的，尽量做到再保证实现功能的同事，设计尽量少量的表。