一、范式
如果详细的讲范式，要写大大大篇文章来讲，这里假设大家知道一些基本的范式规则，我用简洁的语句和例子说明
第一范式：列不可再分，譬如地址字段，可以再细分为省市区门牌号等等（其实还是看需求怎么整）
第二范式：满足第一范式，且除主键以外的列都依赖于主键，这个好理解，订单表中不要有商品名，因为商品名依赖的
是商品id，应该放在商品表中，否则如果商品表中商品名字变了，订单表的商品名却是老数据
第三范式：满足第二范式，且非主键的列不存在传递性依赖，比如订单表中一种常见的不好的设计：
product_name依赖于product_id,product_id依赖于order_id,那么就应该把product_name移除，这是我们常说的冗余字段
范式的优点是结构简单，更新操作快，重复数据少，表规模更小
范式最大的缺点就是通常一些并不复杂的查询都需要关联，稍微复杂的可能要关联多次
二、反范式
如上，反范式的优缺点可以说跟范式正好相反，因为冗余了列，所以更新的时候需要同步更新过去（触发器很方便实现，但是
大公司一般拒绝这样做，因为出了错根本无从排查或很难补救，甚至于存储过程基本也是拒绝使用）。有了冗余列则不需要关联，
意味着使用索引等这样快速的查询更方便
三、混用范式和反范式
实际开发基本都是这样做，是否要冗余还是不冗余，取决于业务，比如一个人的身份证不至于经常变（甚至不变），这样不怎么
变的字段完全可以冗余下来，避免连表查询。再比如count性质的字段，我们不会每次都用一个子查询去计算，而是增加这样一个字
段，每次增加记录后会更新该字段，诸如此类。
四、汇总表、计数表和缓存
一些实时查询代价很大的，我们可以使用汇总表，以前用过复杂的视图，后来发现接触的数据量还是太小，量一上来数据库就要
崩，汇总表就是可以在一个固定的时间点或固定频率做一些汇总查询，将结果保存下来的表，这样每次查询直接拿查询结果即可。这
种设计可能增加写负担，但是显著的提高读性能
五、横向和纵向切分
对于表中字段非常多的表，考虑根据字段意义类别再拆分出一个字表，对于某个字段中需要存储文件或长度很大的字段，也可以
单独拆出来，比如user表中的身份证照片，头像，写真这样的字段，可以独立出字表；
对于时间或者顺序迹象比较明显，数据量又很大的表，考虑分区处理
六、其他
1、表名，字段名使用小写英文字母加下划线命名，用单数形式，表名以t_开头，尽量不要包含数字
2、除非有具体的理由，每张表应该有create_time和update_time两个字段
3、建议每张表都有自增id作为标识列
4、字段名最好不要超过3个单词连接，除非有业内熟知的单词缩写，用完整的单词
5、所有字段名尽量用业内熟知的英文单词，比如账户account，订单order，状态status，类型type
6、设计表时注意预留一些字段，比如常见的物理删除和逻辑删除 ，那么需要预留一个状态字段，如果是激活和非激活状态，也需
要设置一个状态字段
以上是一些比较理论的东西，实际开发设计表，还是需要知其然知其所以然的，否则有可能就是迷迷糊糊的不知道问题出在哪儿