设计思想 分析表每个字段的具体参数。
约束？
NOT NULL, PRIMARY KEY, UNIQUE KEY, DEFAULT, FOREIGN KEY, REFERENCES [ON DELETE CASCADE/ SET NULL/ NO ACTION/ RESTRICT/ SET DEFAULT]
能否复用？
使用额外字段tpye加以区分。
逻辑删除？
使用status字段，is_delete 反范式，create_time
一对多（多对多即两个一对多）的表横行纵向互换？
横变纵：即把这个用户id对应的频道表多加几行。小缺点，id赘余。
纵变横：反过来，即把用户id对应的表多加几列。小缺点，空间浪费。
封面基本不会动，因为会影响推荐。
为减少多表查询的次数需要合并表，怎么解决一个字段保存多个值呢？
用json。
{\'type\':3, \'pic\':{url1, url2, url3}，josn基于longtext类型创建的。 mysql的json这么强大，但用户和频道这种最好不要用json，一个字段对应的数据太大。get。
选json还是纵向连表？
json：少量多值，不经常变化，需大量查询的。如文章的封面。
拆表：不知道有多少的，需大量修改的。比如搜索历史记录的表，比如用户关注你知道关注多少个吗。 关注表里互粉的有两条记录。 数据时代都是逻辑删除。 表的复用。
三级回复再建表？
不用用自关联。 为了查询效率，可以做冗余字段设计（空间换时间的思想，属于一种反范式设计）
看一个人的数据库设计能力？
用了多少反范式的设计，越多越强大。 粉丝，点赞数，评论数全部横向进去，空间换时间的思想。 根据数据范围选类型，每个字段的每个参数都得考虑，我的天。
公司初期用python，后期用go。python能创意快速实现，性能瓶颈地方调用c库。 没有related_name照样能关联查询。
三范式
1NF：列的原子性，列不可再分。
2NF：满足1NF；必须有一个主键；非主键字段必须完全依赖于主键，而不能只依赖于主键的一部分。
3NF：满足2NF；非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。需要把依赖的表拆了。
so easy！2说的是字段完全依赖，3说的是字段直接依赖。
E-R模型
entity-relation，实体关系模型，描述数据库存储数据的结构模型。
E-R模型的使用场景:建模工具如:power designer，db desinger等这些软件来画出实体-关系模型(E-R模型)，然后根据三范式设计数据库表结构。
实体: 用矩形表示，并标注实体名称 属性: 用椭圆表示，并标注属性名称 关系: 用菱形表示，并标注关系名称