一.目录
前言
内容
结语
二. 前言
高手说的简单与菜鸟理解的简单是两个不同的概念，就像富人的小目标与普通人的小目标不能相提并论，在自己能力、认知范围内做出的判断会有偏差。我们不能保证自己是最优秀，但可以保证自己朝着优秀的方向前进，大白话就是：你可以不优秀，但不能太拉垮！人与人差距其实不太大，差距的数量多了就变大了。言归正传，怎么设计好数据库（这里只涉及表、字段之类的，不做深入探讨）呢？
三.内容
设计好数据库要从以下几个方面入手：
- 参考之前的表、字段表命名规则 。表命名规则：库名+业务名+表名；字段命名规则要尽量做到一套系统中基本一致，不能出现在这个表中是stationType，在其它表中是type。
- 字段类型、长度要保持一致。字段长度要预估好，可以设置长一点。之前项目中出现过type长度为1，突然有一天报错的了，原来新需求增加了type刚好超过字段长度。
- 创建必要的索引、约束。比如主外键索引，没有加基本上关联查询都很慢，而且还很难找出问题原因，后面又是一个艰难的优化过程；唯一约束，根据业务场景要创建好，避免在程序层面没有控制好的情况下，数据库也没有控制好。
- 新创建表通常会有主键、创建时间、创建人、修改时间、修改人、状态（为了数据安全绝大多数删除都是逻辑删除）
- 基本遵守“三范式”。
- 确保每列的原子性，每列或者属性值都不可再分的的最小数据单元。举例，用户表：id，用户名，性别，年龄。。。每个字段都是最小的单元，不能再细分。
- 确保表上的每列都和主键相关。比如用户表，角色表，用户表是不能保存用户角色的，一张表通常只记录一类信息。
- 确保每列都和主键直接相关 。主要是Armstrong公理（从已知的一些函数依赖，可以推导出另外一些函数依赖，这就需要一系列推理规则，这些规则常被称作“Armstrong 公理”。）比如，用户表，用户类型表，类型不能存在于‘用户表’。
- 可以做适当字段冗余。
- 关于业务拓展方面设计，比如订单主表（有业务类型，业务id-子业务的id）、订单主表详情、订单各业务的子表；会员表、会员拓展表、第三方用户表。
- 表、字段加上注释。类型、状态代表什么意思要写清楚。
四.结语
之前有网友吐槽项目中出现一个表超过50个字段、表中什么注释都没有，其实这些都项目管理不到位、开发人员素养问题，这两个问题没有解决吐再多的槽也没有用。不过，也有外包开发者也遇到过我就直接劝他重新找工作，因为你没有话语权。
人与人差别除了个人努力等之外，还和环境有关，好的方法、方案不是每个人都知道，能理解，需要时间，需要“鲶鱼效应”。
