1.数据库表业务设计

数据库表业务设计"/>

1.数据库表业务设计

文章目录

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

博客概述

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

主表与子表关联性的思考

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

抽象表与具象表

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