关于网友提出的“数据库概念结构设计 数据库表结构设计”问题疑问，本网通过在网上对“数据库概念结构设计 数据库表结构设计”有关的相关答案进行了整理，供用户进行参考，详细问题解答如下：
问题：数据库概念结构设计 数据库表结构设计
描述:业务需求描述如下：
如上图所示，定义了一组规则，有区域规则，城市规则，机房规则，数量规则，比例规则，类型规则。设置规则的时候，可以将上述规则进行组合，生成一条规则集(由上述规则并集得到)。那么这样可以编辑好多规则集，形成一个list列表。如下图所示：
那么我们定义的规则集就可以生成一组的规则集列表，当生成一个订单，用户可以填写一些规则，那么服务端根据传过来的规则，匹配规则列表中的规则，选择出一堆否和条件的规则，然后按照优先考虑不同快递公司，优先某几种规则，来进行匹配相应的规则，进行物流配送。
请问这个相关的表结构该如何设计？
PS：我的表结构设计是这样的：
条件表 规则表
1.条件表中，存放单独的规则条件，他们可以组合成一条规则集。
2.规则表中，存放组合好的规则。
当web端，选了相应的规则之后，我先将前端的规则进行拆分，从条件表中分别进行匹配，然后匹配得到各种集合，然后用SQL中的in语句，拿得到的这些集合去规则表中去匹配。
第一个问题：
总觉得这样设计效率不高？有没有更好的方案呢？？？
PS:在表结构设计中，类似这种问题叫作：java 规则引擎设计。运用场景还是蛮广泛的，比如，好多电商都有风控的场景，就是一些规则来判定他的一个订单是不是刷单，它会有很多规则，那么根据一条订单的特征，生成一组规则组合，然后用订单规则匹配规则组合，算出当前的订单有多大概率是刷单的，如果刷单概率太大，就到人工审批环节，人工确认刷单后，对相应的商家要进行封号处理。
所以，第二个问题：
特别好奇一些电商或者O2O平台的，风控规则是如何设计和实现的呢？
===============================================================================
后期的发展是这样的，需求方做了让步，不想让80%的工作量带来10%的价值，所以修改了规则匹配算法，只做最精确匹配，匹配失败就不匹配了。
解决方案1:我觉得可以使用3张表
表1. 定义规则的元数据，比如某个规则是对城市的限制，是个枚举类型，另一个规则是对机房数量的限制，是数值型，字段可以是：规则id，类型，取值范围等
表2. 定义物流商和规则的映射关系，字段可以是：物流商id，规则id，规则值
表3. 定义用户订单，描述的是用户选择的规则列表，字段可以是：订单id，规则id，规则值等，一个订单可以有多条规则对应，用订单id可以查询出所有相关的用户指定的规则。
然后程序可以通过用户订单的规则列表去第二张表里找到最匹配的物流商。
回答你，我的见解：
web端要单独展现规则集的，规则集跟订单是分离的。当订单去选择物流配送的时候，才会去匹配规则集。至于表2，感觉没必要啊，物流商和规则的匹配高一个加权的轮询策略就好了，不用单独设计表，查表的效率一般都是很慢的，尽量做到再保证实现功能的同事，设计尽量少量的表。
解决方案2:简单的想法
规则类型表（没什么变化的话，可以放在静态字典里面）
id 规则类型
1 数量
规则表
id 规则类型ID 规程名称
1 1 数量大于100
物流匹配规则表
id 物流ID 规则ID 优先级
查询时
通过查询规则ID in(规则ID) in 效率不高可以改成exists
统计物流ID的个数，达到最优选择，如果有优先级，可以加条件进行判断，如 异地 某个物流根本不送
