关系型数据库应该如何设计表结构----对范式的思考，以及对《阿里巴巴Java开发手册》的理解

一、知识储备

• 第一范式：又叫1NF。符合第一范式的关系中的每个属性都不可再分。
• 第二范式：又叫2NF。规则是要求数据表里的所有数据都要和该数据表的键（主键与候选键）有完全依赖关系：每个非键属性必须独立于任意一个候选键的任意一部分属性。如果有哪些数据只和一个键的一部分有关的话，就得把它们独立出来变成另一个数据表。如果一个数据表的键只有单个字段的话，它就一定匹配第二范式。
• 第三范式：又叫3NF。要求所有非键属性都只和候选键有相关性，也就是说非键属性之间应该是独立无关的。

理解第二范式，第三范式，关键得理解候选键的概念。

候选键：是某个关系变量的一组属性所组成的集合，它需要同时满足下列两个条件：

条件1.这个属性集合始终能够确保在关系中能唯一标识元组。

条件2.在这个属性集合中找不出真子集能够满足条件1。

此外，理解第二范式，还应该理解依赖的含义。

依赖性：
比如说：在一张学生信息表（id为主键），不应该出现course_name(课程名称，依赖于course_id)这样的字段，因为，如果有一天，《心理健康教育》课程名要改成《心理健康教育杂谈》，这就得需要改课程表，还得回来修改学生信息表的课程名称。(原文地址)

二、应用场景下的取舍

范式的设计，主要目的是为了消除数据冗余的。

因为现在的互联网产品，在很多场景下，为了追求速度，提高查询性能，往往是允许数据冗余的。

所以接下来的问题就是，在什么样的场景下，应该遵循范式，避免数据冗余；什么场景下，应该避免被范式束缚呢？

《阿里巴巴Java开发手册》里是这样要求的：

这个举例的商品类目是什么呢？比如一款多媒体音响独立功放低音炮产品，属于的商品类目就是：影音电器==>电脑多媒体音箱。

也就是说，按照阿里巴巴Java规范里的标准设计，一款商品的表里，不仅仅有价格、商品名称字段，还是要有商品类目字段；

而按照范式的标准，特别是第二范式，一款商品的表里，应该把商品类目剔除出去，用商品类目id来替代，然后新增一个表，包含商品类目id，商品类目名称字段。

按照范式的标准来设计表确实是有合理性的：当商品类目需要修改的时候，只需要修改商品名称这个字段就可以了。

但是，修改商品类目名称往往是很罕见的，这个好处并不足以抵消它的代价—降低了查询的速度。

所以在字段名称基本保持不变，且使用频率高的情景下，违反第二范式的好处是大于遵循第二范式的。