学习数据库的套路

【要不要学 or 为什么要学】

很多学生在选一门课的时候，最基本的问题往往不会去关心。同时，学生们也没有权利去选择，毕竟有培养计划这种东西。所以老师
要做的是激发起大家学习的欲望，这一点做的好，往往会水到渠成。
另一个是，你需不需要学，是找别人帮忙，还是自己做？学习数据库你要花费的时间成本是多少，如果我告诉你掌握数据库需要十年，你当然不干了。
我学习数据库，是基于我做项目的需求。很简单，我做Web开发需要存储信息，总不能都靠非结构式文件，而且各种查询处理都不方便对吧。

【DBMS 的选择】

于是搜索数据库，哇好多种DBMS的种类，而且SQL 与 NoSQL 让人眼花缭乱，看需求吧，首先目前做的项目是单个服务器的，所以不涉及分布式，而且是内部访问，并发不高，而且SQL相关的资料又很多，种种原因，选SQL好了，那么DBMS又有很多: MySQL , Oracle,SQL Server 等等，我选了MySQL，主要因为免费，而且DBMS的很多高级功能我暂时用不上，所以就它了。

有人会觉得，NoSQL出来了，而且这么火，关系型数据库真LOW,这种东西早就应该被淘汰了吧，（Sorry，我曾经也属于狂热追求新技术的分子）实际上不然，阿里淘宝等国内的大部分公司依然在用MySQL，无论从就业的角度或者是学习的角度，SQL的学习都是必要的，没有一种完美的解决方案，SQL与NoSQL都有各自的短板，接下来的文章里我们再细谈。

【项目需求分析】

首先目前我想做的是一个XX系统。

我这里且叫它课堂交互系统吧，对，就是花了一年都没做出来的那个，心累。

在数据库设计的第一步，我们要明确需求，就是说，这个课堂交互系统都有哪些功能点，例如：考试开启一次小组互评，小组管理，学生之间的小组互评等等。（在软件工程和产品经理的课程里面有详细的说明）

【概念模型设计】

我有了想做的功能，那下一步要做的是不是就是要分析，每个功能模块中对应的都有哪些"实体" ，实体之间的"联系"，以及实体本身都有哪些"属性"。
但是自己在纸上乱涂乱画，好混乱有没有？所以我们需要借助E-R模型来帮助我们分析关系。

问题 1: 实体之间都有哪些关系呢,每种关系在E-R上都是如何去表示的。

当我想存选择测验的时候
（1）一个测验，可以有多个选择题（好吧 ，主观题/简答题这里我们就先不说了），而一个选择题又可能出现在多个测验中，这叫多对多（Many-to-Many）

（2）一个试题对应多个选项，而且选项不确定。那么好了，这是一对多的关系（单选还是多选，它们都一样吗？存储的方式有啥不同）

（3）最日狗的地方来了，学生做题的记录怎么存？

如上的这一系列的思考，并不是我在做哪套题目，而是我在做这个项目的时候，真真切切需要结局的问题。

问题 2：E-R 如何才能画的好 ？ （结构清晰，分层）
当学会画E-R图的时候，总是发现最后都画成了一坨，而且一个项目的实体又那么多，彼此的关系错综复杂，最后各种跳线，画出了你根本看不懂的E-R图。

你想我都看不懂了，多大的问题！！
所以要学会分层，每个功能模块分开画，细节后述。
这是还可以上升到人生哲学的高度，从顶向下，逐层细分问题，各个击破。完美！

【关系模型】

关系模型是数据模型的一种，因为我们这里要使用的是MySQL，所以我们需要采用关系模式进行分析。
为啥要这样干，因为你又不能通过E-R直接生成表结构。所以你需要将E-R模型“翻译”成关系结构。

问题3 ： 每种E-R中的关系，映射到关系模式中，方式是唯一的吗？E-R图有没有一种设计规则来指导我们呢？他给定的设计规则我一定就要遵守吗？

显然不是嘛。
举例来说E-R模型中的Is-a关系 即 继承关系。举例说明，老师和学生之间的关系，这里他们都是这个系统的用户，老师和学生都可以评价小组展示的内容，包括用户的登陆，注册等等功能模块，老师跟学生是很类似的，最后设计出来的表结构，你会发现列的内容只有很少的差别，这里我们将二者抽象成一个User 实体。

问题来了 ：怎么存？
（1）这两个我能都放在User表中，对一张表，那各有的字段怎么办，比如学生有学号，老师有教工号咋整？冗余字段呗。User中同时有学号和教工号这两列
（2）第二种是Student和Teacher各自一张表，分家了，自己存自己的。
（3）三张表，User，Student，Teacher，User中存取共同的部分，Student，Teacher存各自特有的部分

问题4： 在这里面哪种是最好的设计呢？

Sorry，这里没有标准答案，这也是数据库设计思想里面最吸引我的地方。

范式
虽然有范式（1NF,2NF,3NF,BCNF）的数据库设计理论来消除冗余，但是不必较真，你设计的表结构越分散，就意味着你写查询的时候会很麻烦，耗时也会越长，对大家的要求是，先能够做到功能实现。武林高手的进阶大概会经历这么几个阶段：

没有对错，只有哪个更适合你此时的需求，对此事的，很可能你系统运行一个月之后会变得很卡，问题的答案又会变掉了。

同样的，永远都没有完美的数据库设计，好的数据并不是一开始就设计好的，而是一次一次迭代出来的。（可能是需求变更，也可能是数据库设计的优化）
这里推荐一本书《SQL反模式》。

给老师的建议
其实，设计一个数据库是最简单的，这里我先不说好坏，起码你功能实现了。但是在实际的应用中，我觉得是远远不够的。如何测试一个数据设计的好坏，能不能提供大量的数据存入，然后模拟高并发的访问，测试一个数据库的设计的好坏？
当学生写的一个SQL查询需要执行一天的话，那么，绝对出了问题。 是你数据库设计的问题 （例如：没做好索引）？还是SQL语句的书写需要优化？

【物理模型设计】

现在你有了关系模型，感觉它离着变成数据库中真实的表似乎指日可待了对吧。
别急。。。
（1） 字段属性
还记得你的在数据库的概念设计里面实体有很多属性对吧，例如

学生（学号,学生姓名，年龄，学院ID，专业，注册时间）

属性有了，每个数据采用哪些数据类型呢？你需要了解MySQL中都有哪些数据类型，相似的数据类型区别是啥？

（2） 各种约束
实体完整性，根据某几个字段，定位某个特性的行。这个当然不能呢为空啦，要不你都找不到它了。

参照完整性，例如学生实体的学院ID，学院ID是外码，如果学院ID没有或者对应的学院ID在学院表中不存在，什么鬼，你不属于任何一个学院，那你不是很无助。

用户自定义完整性
简单来说除了上面的两种，其他的用户定义的约束，都属于用户自定义约束。
学生实体中有一个属性是 年龄。
好，年龄对吧，-1岁，显然不行，今年是2016年你2017年出生了这也太玄幻了，穿越了？，1000岁？能活到这个岁数的应该是王八吧。

所以我需要给年龄设定一个年龄范围例如 0- 110
超出这个字段的，我都定义为非法。

【创建表结构】

现在你需要学些SQL了，开始的时候你需要创建一个数据库，在数据库中定义表，定义视图，这种操作都叫DDL（Database Define Language ），对应的你需要用DDL写出Create Table的相应的SQL语句。

【SQL基本操作】

表结构有了，但是你还没有数据，插插插，将数据Insert进你的表中。
我还需要查询表（Select），删除（Delete）一条数据，更新（Update）一条记录。

【加特效 ：数据库程序设计】

视图
触发器
存储结构

Note: 暂时先写到这里，工程经验止于此，不愿意误人子弟。

心灵硫酸

老师的职责
（1） 往那走
给学生方向上的指引，用哪个DBMS，学习方式，学习资源。
（2） 喂，走偏了
点到为止
老师教的越多，学生能够接收的信息也就越少。
克制住，先别告诉他原则，让他们违背，走到坑里，很痛苦，记忆也就更深刻，这样才会有需求。
我们总是被告知，不要这样，要那样！可是为啥呢，我们并没有很深层次的感悟，内心无感。
在合适的地方，合适的时间，合适的地点，给与适当的指引。
温柔的告诉他：“也许你应该看一下课本上XX的部分，可能会对你有写帮助”。

不贪
不要意味的看各种设计指导原则，不要贪多，想掌握全部的SQL，更多的还是根据自己的需求来吧，你需要用到哪些功能，不够再学吗，循序渐进。
学习 = 学 + 习，练习实践很重要。
你学习的内容，能不能转换成生产力，等于你是否在有效学习。

项目导向
项目进行中遇到问题了，有了需求，然后去找解决方案。

不燥
文章前面有提到，不要盲目的追求新技术

接受不完美，并且努力做得更好

给项目管理人员：PDCA理论

PDCA来自于户外拓展理论，同理它也可以放在数据库设计的过程中。
Plan 计划
做计划，一开始就动手做，往往需要频繁的返工。
指定适当的计划，分解任务，逐层分解。
Do 尝试
总计划，不去尝试，等于0。
一开始，计划绝对是不靠谱的，而且项目管理者往往会时间估计的比较乐观，比如我。
所以要去试错，做一个Demo，去验证项目计划的可行性。

Change
在我们不断的尝试的过程中，发现了计划中很多不合理的地方，咋办，改计划呗。
循环往复执行，直到计划靠谱。

Action
不要怂，开始动手做吧。