你的业务是可变的吗

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

业务场景

不知道经过D妹子的阐述，你们了解状况了没。这里菜菜再详细说一下。D妹子的程序记录了订单的log来供其余业务（好比统计）使用，这里就以统计业务来讲，OrderLog表设计以下：

列名	数据类型	描述
OrderId	nvarchar(100)	订单号，主键
UserId	int	下单用户id
Amount	int	订单的金额
其余字段省略...

除此以外还有一个用户信息表UserInfo，设计以下： 列名	数据类型	描述
UserId	int	用户id，主键
ProvinceId	int	用户省的id
CityId	int	用户市的id
CountyId	int	用户区县的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

列名	数据类型	描述
Id	int	主键Id，主键
UserId	int	用户id
ProvinceId	int	用户省的id
CityId	int	用户市的id
CountyId	int	用户区县的id

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

列名	数据类型	描述
OrderId	nvarchar(100)	订单号，主键
UserBId	int	对应用户表中的主键id
Amount	int	订单的金额
其余字段省略...

这样设计的话，若是用户的省市区县信息有变更，相应的用户信息表中会存在多条用户省市区县数据

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

改进业务数据表

根据业务的变性和不变性，既然把订单区域统计的业务定义为不变的业务性质，那订单的log表彻底能够这样设计

列名	数据类型	描述
OrderId	nvarchar(100)	订单号，主键
UserId	int	下单用户id
ProvinceId	int	用户省的id
CityId	int	用户市的id
CountyId	int	用户区县的id
Amount	int	订单的金额
其余字段省略...

写在最后

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

但愿你们有所收获 --菜菜

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