MYSQL数据库设计（一）

MYSQL数据库设计

卷首

一个设计精良，结构合理，并且易于维护的数据库可以大大削减在随后工作中的一些性能问题，前期做的工作越多，后期做的工作就越少。

思考示例：

假如有一位老师开设了一门课程，对于选择这门课程的同学需要建立一个数据库来存放数据，这样一个数据库设计时，我们需要考虑那些制约性能的因素呢？

好吧，就假设我们这位老师就是我们亲爱的高数老师，那么他开的课程必须就得是高数了吧，这应该没什么问题。接下来，比如说，有三位同学选修了这门课程（人气有点惨淡啊，才三个人的说...），这三位同学分别就是，小明，小暗，小不点，他们三个人都有自己的学号和班级等等一系列信息。

好吧，下面列出基本的信息

姓名	学号	选课
小明	小明的学号	高数
小暗	小暗的学号	高数
小不点	小不点的学号	高数

基本信息有了，我们如何来设计一个数据库呢，

或许大家都会想到的一个版本是这样的：

Student_ID（PK）	Name	class
1	小明	高数
2	小暗	高数
3	小不点	高数

OK，这样设计是没有什么大问题的，它也能正常使用，但是有一个问题我们可以好好思考一下，这样的数据库结构是一个容易维护的数据库么，它使用以后，维护起来会不会有什么问题呢?

接下来重头戏来了，假如说我们这位高数老师突然觉得：哎呀，不行，我这课选课人数这么少怎么行，我得想办法让更多的同学们来选我的这门课。于是乎，这个老师想到了一个绝妙的主意—改个名字，改什么名字好呢，老师想了想突然一拍大腿，不如就叫微积分吧。这个时候，大不点选课时突然看到有个课的名字叫做微积分，他瞬间觉得这门名字是如此的高深（逼格略高），以前从没听过，于是乎，他也就一拍脑门，决定就选这个课了，好回去和哥们吹牛，享受一下牛逼轰轰的感觉。

故事到了这里，本来对于老师和选课的同学都没什么问题。老师甚至想想，哎呀，这又多了一位同学选课，内心还有这么一点小激动呢。大不点同学也还沉浸在意淫自己享受牛逼轰轰的感觉之中。

但是这个时候，数据库管理员不干了，老子辛辛苦苦建了一个数据库，容易么我，你们倒好，课程名字说改就改，到头来还不是老子来收拾烂摊子。一边抱怨，一边把数据库所有选修高数的同学都改为了选修微积分。（故事到了这里就算告一段落，其实上文纯属虚构，请大家一笑而过）

事实上，这个故事中的数据项只有三项，真正需要修改工作量并不大，就算有数据库有几十项，修改起来也不是太麻烦的事，但是如果这个数据库有上万条记录又怎么办呢，其实修改起来没想象的那么复杂。

只是多费点功夫罢了。

但是从数据库的可维护性上来说，这个数据库设计的并不太理想。一种好的想法就是，分离表中重复性的字段。即我们可以把表设计成如下的形式。

表一

class_ID	class
101	高数

表二

Student_ID（PK）	Name	class_ID
1	小明	101
2	小暗	101
3	小不点	101

这样一来，再遇到像上面类似的问题，我们就可以舒舒服服的只用把表一中的class字段中的高数改为微积分就行了，不管表二中有多少数据项，我们都只用修改一项。

调整过的数据库如下：

表一

class_ID	class
101	微积分

表二

Student_ID（PK）	Name	class_ID
1	小明	101
2	小暗	101
3	小不点	101
4	大不点	101

这就是一个可维护性明显优于之前的数据库的一个例子。