mysql优化之表的设计

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

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

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

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

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

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

在设计订单表的时候，一般会有以下的字段

ID	order_num	add_time	order_time	info_id	user_id	content	...	...
1	XXXXXXXX	....	..........	.........	...........	.........	.......	.....
2	xxxxxxxxxxxxxx	....	..........	............	..........	........	........	........

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

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

比如

class表

ID	class_name	teacher_name	...
1	软件工程	张XX	...
2	网络工程	李XX	...

student

ID	name	qq	tel	class_id	class_name	teacher_name	.......
1	王XX	10001	.........	1	软件工程	张XX	.......
2	赵XX	10002	..........	2	网络工程	李XX	.....

大家这个时候可以看的出来，在student表里面的class_name和teacher_name没必要罗列出来，可以根据class_id获取的到。

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

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

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

就简单的做个表格。

这个是相册的表

ID	相册名字	views	....
1	XXXXX	100	...
2	xxxxxx	66	....

相片的表

ID	相片名字	view	相册ID
1	XXXXX	55	1
2	xxxxxx	66	2

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

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

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