image

请不要跟我说用ES或者其他,其实很多中小公司的业务就是如此,就是基于mysql或者sqlserver 来搞这样的业务

业务场景

不知道通过D妹子的阐述,大家了解情况了没。这里菜菜再详细说一下。D妹子的程序记录了订单的log来供其他业务(比如统计)使用,这里就以统计业务来说,OrderLog表设计如下:

列名数据类型描述
OrderIdnvarchar(100)订单号,主键
UserIdint下单用户id
Amountint订单的金额
其他字段省略...

除此之外还有一个用户信息表UserInfo,设计如下:

列名数据类型描述
UserIdint用户id,主键
ProvinceIdint用户省的id
CityIdint用户市的id
CountyIdint用户区县的id
涉及到拆单等复杂的订单操作,表的设计可能并非如此,但是不影响菜菜要说的事

变数的业务

现在假如要统计某个省的订单总数,sql如下:

select count(0) from OrderLog o inner join UserInfo u on o.UserId=u.UserId where ProvinceId=@ProvinceId

有问题吗,sql没问题,这时候用户A的省市区县信息突然变了(也许是在其他地区买房,户口迁移了),也就是说UserInfo表里的信息变了,那用以上的sql统计用户A以前省市区县的订单信息是不是就会出错了呢?(产品狗说在哪下的订单就属于哪的订单)

业务的定位

以上的问题你觉得是不是很简单呢?只要稍微修改一下表也许就够了。但是,菜菜要说的不是针对这一个业务场景,而是所有的业务场景的设计。那你有没有想过为什么D妹子的设计会出现这样的问题呢?

深刻理解业务才能避免以上类似的错误发生,一定要深刻理解不变和可变的业务点。 拿D妹子的统计来说,你的业务是统计区域的订单数,这个业务在产品设计上定义的是不变性,也就是说在行为产生的那个时间点就确定了业务性质,这个业务的性质不会随着其他变而变。具体到当前业务就是:用户在X省下的订单不会随着用户区域信息的变化而变化,说白了就是说用户在X省生成的订单永远属于X省。

谈到业务性质的不变性,对应的就有业务的可变性。假如你开发过类似于QQ空间这样的业务,那肯定也做过类似访客的功能。当要显示访客记录的时候,访客的名称在多数情况的设计中属于可变性的业务。什么意思呢?也就是说一个用户修改了姓名,那所有显示这个用户访问记录的的地方姓名都会同时改变。

说到这里,各位再回头看一下D妹子的业务,这里又牵扯到一个系统设计的问题,众所周知,一个好的系统设计需要把业务的变化点抽象提取出来,D妹子订单统计的业务变化点在于用户的省市区县会变化,订单的金额、订单号等信息不会变化。所以你们觉得是不是D妹子的数据表可以修改一下呢?

数据表的改进

改进用户信息

按照以上的阐述,D妹子业务的变化点在于用户的省市区域信息,所以可以把用户信息的表抽象提取出来,主键不再是用户id

列名数据类型描述
Idint主键Id,主键
UserIdint用户id
ProvinceIdint用户省的id
CityIdint用户市的id
CountyIdint用户区县的id

这样的话用户订单log表中就变为

列名数据类型描述
OrderIdnvarchar(100)订单号,主键
UserBIdint对应用户表中的主键id
Amountint订单的金额
其他字段省略...

这样设计的话,如果用户的省市区县信息有变动,相应的用户信息表中会存在多条用户省市区县数据

这里的用户信息表并非是用户对象的主表,而是根据订单业务衍生出来的表

改进业务数据表

根据业务的变性和不变性,既然把订单区域统计的业务定义为不变的业务性质,那订单的log表完全可以这样设计

列名数据类型描述
OrderIdnvarchar(100)订单号,主键
UserIdint下单用户id
ProvinceIdint用户省的id
CityIdint用户市的id
CountyIdint用户区县的id
Amountint订单的金额
其他字段省略...

写在最后

各位读到这里,可能会感觉菜菜这次写的其实很鸡肋,但是,D妹子的场景却是真实环境中遇到的问题。问题的本质还是变性业务和非变性业务的定义和划分,和架构设计一样,数据库的设计其实也需要把变动的业务存储点进行抽象,其实应该说是抽离出来。

希望大家有所收获 --菜菜

领取架构师进阶资料大礼包


菜菜
76 声望13 粉丝