运维开发中数据模型的流程化管理

这是学习笔记的第 1842篇文章

一个系统里面存在几十张表是很正常的事情，如果表数据量巨大，而且随着业务场景的结合，越来越复杂的时候，就会发现原本对于模型的处理就是一种捏橡皮泥的感觉，你得自己手工捏出来它预期的效果，每改一处就需要重新塑造，伤筋动骨。从可持续的迭代改进来说，是到了要重构的阶段了，而如果忍住了坚持下去，会发现规避的问题比带来的问题更多。

对于模型的管理，一种经典的设计思想就是ORM,当然行业内也有很多成熟的方案，在这方面我暂且以基于Django为基础来简单说下，其实和Django的技术细节无关。

首先我们创建了多个model,从数据库层面就会映射出多张表，有的是一对多，有的是多对多。从设计的角度来说，我对model的使用是一种单一的需求，即不希望存在外键，不追求极度设计，允许部分冗余。

当然这对model的管理本身没有变化，基于model的处理有以下的集中设计思路，一种是原生的API方式，比如Django API等。还有一类是作为RESTful API使用比较轻量的方式，基于序列化方案的设计，这类方案相对来说比较精巧，代码量小，没有Django API的功能全面，主要是做模型映射，通常会和API结合使用，不适合一些定制化数据格式的场景。还有一类是raw sql,这是API和序列化之外的下下策。如果确认难以通过上述两种方案满足，使用原生SQL也是支持的，不过不推荐首选。

最硬伤的，如果添加字段，修改字段名等，raw sql方式就很难以扩展。

当然这些都是底层偏技术的事情，如果再上升一层就会发现，问题的复杂度远比这些要高很多。 为此我画了一个图。

比如model1的数据变化会联动引起model2的数据变化，就跟一层麦浪一样，其实这种场景是很多的。所以如果要把这些关联联动起来，着实是一件很繁琐的事情。

而对于数据的管理不只有正向的联动，如果反向的联动，也是有的，比如刚刚是model1的变更联动model2的变更，反之model2的变更也会联动model1的变更，随着业务场景的组合，会发现这个部分会越来越复杂，所以我们要抽象出一个DAO层来统一处理业务层的数据联动。

而且对于业务层的数据联动，需要通过可配置化的方式实现联动，这样的形式算是一种扩展而且易定制的方案。