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

这是学习笔记的第 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层来统一处理业务层的数据联动。

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

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-12-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券