数据库设计原则，或者说最终目的：
- 有效的存储
- 高效的访问
最近在慕课网上学习了一部分数据库方面的理论知识（最近学习喜欢从视频入手。。。好像也就到视频和写博客了），现总结如下；
总体结构：需求分析——》逻辑设计——》物理设计——》维护优化；
实际上，讲者也认为，数据库设计就是一个需求，而整个设计就包含上面的四个步骤；
总述
直接上图
下面是文字版
- 需求分析：分析整个数据库要存哪些数据，这些数据本身有哪些特点，数据之间存在什么关系（明确数据，明确数据特点，明确数据关系）；
- 逻辑设计：针对上一步中的数据特点和关系构建模型/关系图；
- 物理设计：把上一步中的设计在数据库创建中实现；
- 维护优化：根据需求变化和性能变化，对数据库进行维护或优化；
需求分析
举个栗子：
上面生动的演绎了如何分析数据库需求，然后画图的过程，不再赘述；
逻辑设计
首先是ER图的设计：
然后是各种范式：
- 第一范式：每个属性单一不可拆；
- 第二范式：表中无冗余，不存在部分函数依赖关系；
- 第三范式：不存在传递函数依赖
是不是看不懂，嗯，说不定过一段时间我也看不懂了，需要一些解释才行：
知乎上的关于范式的回答
其实有几个点需要注意下：
- 范式会“向下兼容”；
- 最基本的1范式一定要满足；
- 一般满足到BC范式即可；
- 为方便和性能考虑，大多数时候需要反范式设计；
下面上图：
物理设计
物理设计主要是把想要的落到实处，这里就是建库建表，所以就涉及选择什么库，以什么规范建表，表中字段怎么设计的问题了；
直接给出结论：
- 对于互联网项目，请直接选用MySQL；
- 表结构设计请遵循1NF以及适当的反范式设计；
- 表字段请遵循可读性设计；
- 数据类型选择请选用业务适用基础上的最优选择；
- 主键直接用id就好；
用图说话：
关于外键、触发器、预留字段的禁用，可以再深入研究下；当然，工作中都在用ES，后面要琢磨下了
维护优化
维护优化是为了更好的使用数据库，所以针对可能出现的情况进行处理：
- 忘记这个字段的含义了——》做好COMMENT
- 查表速度慢——》索引的维护；
- 数据太多了——》拆表
这一块要说的不多，都是经验之谈，后面有相关经验了再补上；
