前言：
不知道现在的大学里面，在学习关系数据库时，还提不提数据库三范式
第一范式：列不可拆
第二范式：主键唯一
第三范式：外键关联，避免数据冗余
数据库发展到现在，无论是从数据库本身的设计层面，还是业界对于数据库的使用层面，上述三范式中，除了主键唯一这个范式还被遵守，其余的两个都已经被突破了。首先，"列不可拆"，MySQL 5.7 之后引入JSON类型，突破。其次，"外键关联，避免数据冗余"这点，在分布式应用，分库分表的场景下，比如陆金所，应用层禁止一切关联查询。其他的一些大厂，禁止三张表以上的关联查询，而且为了减少DB IO次数，在设计上会支持一定程度的数据冗余，第三范式也被突破。
业务需求变动的时候数据库设计面临的问题
很多的系统，从分层上都是这样的，见下图。
image.png
有句话叫“世界上唯一不变的是变化本身”，软件系统也不例外，当系统上线之后，产品经理跑过来说"XXYYZZ，很简单的。",然后你从DB开始进行变更，然后到SQL，加上DAO，SERVICE，WEB层的各种DO，DTO一路改下去；没过几天，产品经理又来了，循环往复。那么从设计上有没有办法来规避呢？
数据库设计如何应对需求变动
1.主表，拓展表
在设计的时候，将主要属性，或者说第一个版本的属性，直接放入主表，后续有新加的字段，直接放入拓展表中。
以员工表为例，主表中存姓名，年龄，入职日期这些字段，后续需求变动，产生的新字段直接以key，value的形式存在拓展表中。比如需要加一个职级，就在拓展表里加一条记录，key="emp_level"，value=”研究员“。
image.png
那么在应用层面，拓展表的信息是怎么体现的呢?在DO层面有一个Map属性，用来存拓展信息
public class Employees {
private Integer empNo;
private Date birthDate;
private String firstName;
private String lastName;
private String gender;
private Date hireDate;
private Map<String, String> extInfo = new HashMap<String, String>();
}
每一个查询，需要两个sql，一个sql查主表，一个sql去查拓展表，查完之后，再将拓展表的查询结果装配进extInfo属性中。
这种方案我个人认为比较复杂，数据库层面多了一个表，而且一组key：value就需要增加一条记录，会增加数据量级；应用层面的问题是，需要有一个装配拓展属性的工作量。
2.JSON类型的字段
这种方案是，在主表上直接预留一个JSON类型的字段，如果数据库版本不支持，直接使用String字段。
image.png
需求变动的时候，json本身就是一个变化的结构，可以很好的应对。
这时候，DO变成了下面这样,之前的Map属性直接变成一个json串。
public class Employees {
private Integer empNo;
private Date birthDate;
private String firstName;
private String lastName;
private String gender;
private Date hireDate;
private String extInfo;
}
相较于主表，拓展表的形式，此种方案在表结构上，就一个表；应用层面，一次查询即可，也无需开发属性填充的功能。如果调用方可以直接解析json，这种模式在面对变动的时候，一行代码都不用改。
总结：面对需求变动，如果一条线改到底，开发工作量大，测试风险也会变大。主表拓展表的方案，在数据库和应用层，复杂度提高了，我个人认为最优解是json结构的字段。当然具体问题还需要具体分析，每一种方案都有其缺点，以json方案为例，如果需要对json中的字段作为查询条件，那么其性能还需要进行特殊处理，后续有时间会再研究下mysql的json字段。
网友评论