mysql怎么设计库、设计表

一. 设计表/库

　　设计思想就是要分析表每个字段的具体参数，包括但不限于以下几点：

　　约束？

　　　　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 依赖于主键的情况。需要把依赖的表拆了。

　　2说的是字段完全依赖，3说的是字段直接依赖。

 

三. E-R模型

　　entity-relation，实体关系模型，描述数据库存储数据的结构模型。

　　E-R模型的使用场景:建模工具如:power designer，db desinger等这些软件来画出实体-关系模型(E-R模型)，然后根据三范式设计数据库表结构。

　　实体: 用矩形表示，并标注实体名称 属性: 用椭圆表示，并标注属性名称 关系: 用菱形表示，并标注关系名称 关系也是一种数据，需要通过一个字段存储在表中（多的一方）。