mysql优化之表的设计

自从阿里推出去IOC的概念之后，就越来越多的人放弃了oralce以及其他的数据库，转向mysql(不过之前的用户使用率也是不低的啊 //:手动滑稽)

然后好多的人在开发的时候，就会对数据库优化这一块越来越蛋疼。查询的时候慢的要死，一看表，乱七八糟的。没一点的设计逻辑，也不根据数据库三范式来设计数据库。不过，现在问那些刚从学校出来的人，问他们三范式，他们还能回答的出来，像工作两三年的又不是DBA的亲，都不怎么知道三范式，我也是最近翻到这一块了，才又温故了一遍。下面直奔主题

--------------------------------------------------------------我是分割线----------------------------------------------------------

表的设计，只有在满足1NF了 才能满足2NF 进而满足3NF

1NF：就是表的列具有原子性，不可以在分解。意思就是表的数据不能在分解。不过，现在像我们经常用的关系型数据库(mysql/oracle/db2/sql server...)都是关系型数据库，这些关系型数据库也都自动的满足了第一范式。

2NF：第二范式也就是对数据的唯一性，不过大部分也都是满足的，很少有不满足的，毕竟都是有主键嘛。不过  对于主键来说，最好不要参与逻辑，只是起到一个标记作用即可。我遇见了不少就是拿主键ID去做查询使用了。下面罗列一个例子

在设计订单表的时候，一般会有以下的字段IDorder_numadd_timeorder_timeinfo_iduser_idcontent......1XXXXXXXX
.......................................................2xxxxxxxxxxxxxx


....

........................................................这个时候的ID大部分都是主键，也就是不会重复，所以，自动的就是满足了2NF。然后就是这个ID不要参与逻辑，这个时候在重新定义一个ID，也就是订单标号来代替ID来使用。用于表和表之间的关联

3NF：是对字段冗余性的约束，当设计表的时候，有些字段是可以能推出来的。这个时候，就不要画蛇添足的给它设计出冗(无)余(用)字段

比如

class表

IDclass_nameteacher_name...1软件工程张XX...2网络工程李XX...student

IDnameqqtelclass_idclass_nameteacher_name .......1王XX10001.........1软件工程张XX.......2赵XX10002..........2网络工程李XX.....大家这个时候可以看的出来，在student表里面的class_name和teacher_name没必要罗列出来，可以根据class_id获取的到。

然而，有时候设计的时候还会设计反3NF，比如：

在设计相册的时候，会设计出相册的浏览量，在图片的时候，也会有一个相片的浏览量。在设计这个浏览量的时候，会出现反3NF设计的做法。

我这的网速比较差，想截图给大家，但是，网速太差，实在是不能上传不了。

就简单的做个表格。

这个是相册的表

ID相册名字views....1XXXXX100...2xxxxxx66....相片的表

ID相片名字view相册ID1XXXXX5512xxxxxx662相册的表的浏览量其实也可以根据相册的ID在相片中搜索到浏览量，然后sum（）计算出浏览量。但是，这样的话 就会导致速度变慢。所以，这个时候会做出反3NF的设计。

以上就是我对于表设计的理解。有各位看官不赞同的请在下面留言。

如果你觉得我写的还可以，请关注我的公众号，为我加油喝彩