MYSQL数据库设计
之二
一个设计精良,结构合理,并且易于维护的数据库可以大大削减在随后工作中的一些性能问题,前期做的工作越多,后期做的工作就越少。
思考示例2:
假设上次那个数据库由于设计得不合理,导致修改起来灰常的麻烦,学校方面出面已经严重警告了设计数据库的那位程序员(好吧,悲剧的总是程序员,鞭子在哪里?? 赶紧捆着客户开抽吧^~^),勒令他必须迅速设计出来一个结构良好而且满足更多数据的一个数据库。
不管这位程序员心里是把这边的全家问候了多少次,但是该做的还是要做的,面对比上次更加复杂的数据库。我们这位郁闷的程序员又该怎么设计数据库呢?
示例如下:
学号 | 姓名 | 选课1 | 课程1详情 | 选课2 | 课程2详情 | …... |
1 | 小明 |
|
|
|
|
|
2 | 小暗 |
|
|
|
|
|
3 | 小不点 |
|
|
|
|
|
4 | 大不点 |
|
|
|
|
|
继续来设想一下
如果数据库设计成这个样子的话:
Student_ID(PK) | name | class1 | class_info1 | class2 | class_info2 |
1 | 小明 | 高数 | XXX | 计算 | XXX |
2 | 小暗 | 高数 | XXX | 英语 | XXX |
3 | 小不点 | 高数 | XXX | 语文 | XXX |
4 | 大不点 | 高数 | XXX | 物理 | XXX |
那么如果再次遇到上一篇中的那位“聪(逗)明(逼)”的老师,我们这位亲爱的程序员怕是要吐血三升而亡了吧~
这种结构的数据库,可维护性不太高。而且修改扩展也不大容易。
其实诸位聪明的读者,遇到这个问题,大家应该都想到上一篇中那种设计的方式了吧
我们可以把课程信息单独提取出来,那么上面的数据库我们就可以设计成如下模式
表一
Student_ID | name |
1 | 小明 |
2 | 小暗 |
3 | 小不点 |
4 | 大不点 |
表二
Student_ID | Class_ID | class_name | class_info |
1 | 101 | 高数 | XXX |
1 | 102 | 计算 | XXX |
2 | 101 | 高数 | XXX |
2 | 017 | 英语 | XXX |
3 | 101 | 高数 | XXX |
3 | 008 | 语文 | XXX |
4 | 101 | 高数 | XXX |
4 | 103 | 物理 | XXX |
这样一来,如果需要修改某位同学的选课情况,只要修改表二中对应学号那一行的信息就行了。
比如说,如果小不点同学听说音乐课上美女很多,那么他抱着某种目地(你懂的),所以又选修了一门音乐的话。这个时候,程序员只需要在数据库之后再插入一条数据即可。如果,采用原来的书据库的话,那就必须要调整整个数据库结构,代价就会很大。程序员要想修改的话,估计就是要仆街的节奏了。
修改后的表二如下:
Student_ID | Class_ID | class_name | class_info |
1 | 101 | 高数 | XXX |
1 | 102 | 计算 | XXX |
2 | 101 | 高数 | XXX |
2 | 017 | 英语 | XXX |
3 | 101 | 高数 | XXX |
3 | 008 | 语文 | XXX |
4 | 101 | 高数 | XXX |
4 | 103 | 物理 | XXX |
3 | 241 | 音乐 | XXX |
只要加入一条数据项就好,可维护性比那个设计糟糕要好上不少(好吧,其实上面那个数据库基本没有什么可维护性)
这样的数据库就叫做满足第一范式的数据库。
规则如下:
1.去除重复的信息
2.为相关的数据单独建立一个表
好吧,说道这里,这位程序员觉得,我这样设计应该就没问题了吧,但是,某位资深程序员路人甲看过之后笑而不语。路人甲故意装作很严肃的样子说:“就问一个问题...”, “爱过”,程序员仰面45度深情地回答道。~咳咳~,嗯嗯嗯~,好吧,诸位不要想歪了
原场景是这样的,路人甲问道:“你这么设计,你爸妈知道么?”(博君一笑,勿喷)
这里的设计有什么问题呢,试想一下,如果现在比如说四位同学,各自选了十一二门课,这样一来,中间肯定有不少重复信息吧,就像我们上表中设计的,四个人都选了高数那么,如果再于到改课名的情况,那不就要把所有的相关条目都要改一遍。这么想想,是不是应该还有点小激动啊(找虐呢吧你~)。
所以说啊,遇到这么一个情况,经典做法是将上面的两表再度拆分,化成三个表。
其实表一基本不用变化,只要将表二拆分即可
具体如下:
表一:
Student_ID | name |
1 | 小明 |
2 | 小暗 |
3 | 小不点 |
4 | 大不点 |
表二:
Student_ID | Class_ID |
1 | 101 |
1 | 102 |
2 | 101 |
2 | 017 |
3 | 101 |
3 | 008 |
4 | 101 |
4 | 103 |
表三:
Class_ID(PK) | class_name | class_info |
101 | 高数 | XXX |
102 | 计算 | XXX |
017 | 英语 | XXX |
008 | 语文 | XXX |
103 | 物理 | XXX |
这个时候,如果再遇到要修改课名或者加选课程,再或者改课神马的就会方便很多
对了,忘了说的一点就是,类似于上面这种设计,就叫做满足第二范式的数据库。
规则如下:
- 没有依赖于主键的一部分非主键属性。
-
- 好吧,数据库设计就这么愉快的结束了,若有在百忙之中阅读的,感谢拍转,以及没经本人同意的请不要随便乱转哦,转了万一吓到小朋友怎么办?就算不会吓到小朋友,吓到花花草草的也是极为不好的 ^_^
-
- 若有不妥的地方,欢迎大家指出,不胜感激 ...