1.数据库表业务设计

文章目录

  • 博客概述
  • 主表与子表关联性的思考
  • 抽象表与具象表

博客概述

这篇博客会记录在实战中对数据库表业务设计对经验,因为接触到到项目水平有限,所以经验仅供参考,记录下来,作为自己到收获,也希望可以帮助到有用的人。

主表与子表关联性的思考

在业务改动与设计中,要增加一个字段,如何判断该字段应该添加在哪里呢?之前的一段时间,老是喜欢加在主表中,把主表做的“又大又肥”,这种方式的好处比较直接,返回的数据是大杂烩,啥都有。但是问题也很明显,会产生维护灾难,后期的维护会很难进行。还需要考虑的一个点就是对某字段可能产生业务扩展扩展,也就是所说的需求更改,会不会增加很多该字段的联系字段?出于这种角度考虑,添加新字段的时候,如果业务上情形比较复杂,并且会关联到其他接口的情况下,还是用子表进行附加会比较灵活。
总结:在表设计中,要灵活对一张大表进行拆分,从数据库设计的角度模块化,一张抽象表,挂很多特征表,需要扩展就继续挂特征表,比较容易扩展与维护。个人感觉这个思路非常好。

抽象表与具象表

这两个概念是自己在项目中创造的,怎么理解呢?举个例子来说,如果网站卖一种产品,这种产品有四种体现,各有特征字段,那是不是意味着必须设计四张表来表示呢?假设我们按照这个思路,可能有4种controller,4种service…,如果出现产品的类型增加,也是有特征字段的,天呐!那维护肯定是个灾难了。面对这种情况,我提出了抽象表与具象表的设计。
所谓抽象表何解呢?还是用上面那个例子,一种产品,四种具体的类型,我们设计一张通用product表,里面有公共字段,比如产品名字这种,总该都有吧!然后呢?重点来了,在product表中设计一个type枚举类,标记这种产品属于哪种类型,如果类型实在太多,可以通过type表来管理。然后以product表为抽象表,对不同对产品,设计具体对具象表,通过productid来与抽象表产生关系,这种设计非常松散,扩展性从个人的角度也是十分好的,推荐给可能需要的朋友!

你可能感兴趣的:(数据库相关)