三大范式：第一范式，第二范式，第三范式，听着名字就很恐怖。但其实现在的人都被这个所谓的第三范式折腾死了，有事没事就拿出来涮涮，究竟怎么理解这些呢？一个一个慢慢的介绍。
数据库理论家们为数据库的设计1对N，N对N这种问题总结出了一个通用的解决方案，只需一步一步地三个范式（Normal Form）的规则应用到自己的数据库上就可以了。
第一范式的规则：
1、内容相似的数据必须“消除”（所谓消除，即再创建一个表来存储他们）
2、必须为每一组相关数组分别创建一个数据表
3、每条数据记录必须用一个主键来标识
第一条规则，看上去就比较适用于1对多的情况
第二条规则就不太好控制了，很多人认为第二条规则很难理解，数据的相关度，很难简单的描述清楚
第三条规则其实是一个实践经验，它的意思是数据表里的第一个数据行都应该包括一个独一无二的标识符作为索引。在使用MYSQL的时候，我们大多采用了自增字段来作为主键，但并非只有整数的自增字段才能作为索引，只要是独一无二的数据列，都可以用来做索引，之所以采用自增列，那是因为：1、不需要主动插入值2、整数列的时间和空间效率相对比其他类型的要高。
第二范式的规则：
1、只要数据列里的内容出现重复，就意味着应该把数据表拆分为多个子表
2、拆分形成的数据表必须用外键关联起来
第二范式，其实是在第一范式的基础上再进行一个拆分。指的就是第一范式规则的第二条内容。
外键关系在第二范式里显得特别重要，是因为第二范式时，数据会拆得更细，如果没有外键关联，恐怕数据就找不回来了。外键相当于我们日常所说的：交叉引用，对开发人员来说相当于指针。
第三范式的规则
第三范式只有一条规则：与主键没有直接关系的数据列必须“消除”
其实也就是把第二范式再分解，再建表。
可想而知，等到真正把一堆数据完全按照第三范式来进行设计的时候，恐怕在数据库里也就只能看到一堆ID了，数据呢？数据在哪里？通过外键，外键的外键，外键的外键的外键来慢慢的一个一个搜索吧。
对于MYSQL 4.1以下的版本，第三范式是会要了他们的命的，foreign key功能的不完善，让MYSQL 4.1以下版本，基本不适合第三范式，能用到第二范式设计时，数据表的效率已经几乎不能保证了。
这三个范式是著名学者E.F.Codd最先提出来的，后人在此基础 上对大到数学集合理论、小到关系数据库设计细节等诸多方面进行了研究和探索。如果对这方面有兴趣的朋友，还是多找找相关的书籍看看为好。
如果你的性子比较急，那么你可以尝试按照下面的方法来进行：
1、设计数据库的时候，一定要给自己充足的时间，如果等到数据库充满了数据，而程序也几乎开发完毕时，才发现数据库设计有缺陷，那么花费的代价就太大了
2、如果发现自己创建的表的数据列有序号，如name1,name2等，那一般就意味着还有更好的解决方案没有采用。可以考虑多创建一个表，而把这些分拆开。
3、第一时间往数据库里多插点测试数据，如果发现冗余量很大，往往就是表需要分拆的信号
4、设计时应该注意数据与数据之间的关联及引用关系
5、对于设计完的数据库，应该自己尝试写SQL语句，看看能否达到你预想的目标，如果达不到，那就要考虑是否设计的有问题。
6、如果你还是等不急，根据你的需要，到网上找找有没有类似的示例数据库，可以考虑拿来作借鉴。
说了这么多时间的范式，最后再说说他们的优缺点吧
缺点：数据表的个数越多，也就相对证明了从表单里获取数据并往表里插的时候，复杂性非常大，给开发人员会带来很大的困扰。同样，表多了，查询结果时，从中提取相关数据生成查询结果的复杂性也就越大；数据库的容量随着表的拆分量的增大而增大（不过现在也不是什么矛盾了，硬盘的价格几乎也快到了白菜价了，这点可以被忽略）
优点：严格按照范式设计出来的数据库，能够提供最丰富、最灵活的查询选项，人们往往都是在等到必须使用一种新的查询或者必须对数据进行一种新的分类时才会真正意识到这一点，但可惜的是，这些新需求往往都是出现在数据库已投入运行数月之后，到时候再改数据库，代价非常大。
现在工作有点忙，连载不会忘记，但更新频率会放慢，毕竟全部都是手工打出来的字。
不会象写小说那样太监掉的，毕竟这个东西对我自己来说，也是一种学习
给自己加油，为自己打气。也谢谢大家的支持
