世界上最遥远的距离不是我不能说我爱你，而是想你痛彻心扉却只能深埋心底。——《我在未来等你》
1、引言
第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。
根据数据库设计的第三方式，在数据库设计过程中，应该尽量消除冗余。即设计数据库时，某一个字段属于一张表，但它同时出现在另一个或多个表，且完全等同于它在其本来所属表的意义表示，那么这个字段就是一个冗余字段。
随着企业数据量与并发量不断的增加，冗余字段的存在到底是好还是坏呢？
根据第三范式而言，冗余字段是垃圾的数据库设计。
2、举例说明与研究
所有问题出现必然因为场景问题，针对冗余字段问题，分为两个场景：
（1）快照场景（副本场景）：交易场景大部分是数据快照，而不是冗余，用户下单时候的用户名、地址、商品名称、商品描述等，若采用关联，商品在下单后发生了更新的话再去关联查询就会导致和用户操作时的数据不一致，从而产生纠纷。
（2）冗余场景：一般数据改动的可能性少，而查询多的场景会使用冗余，例如淘宝的店铺名称，淘宝商家中心会有这个字段，可能里面的商家论坛也有，再假设聚划算这种独立的大业务自己也存一份，再来个垂直频道电器城的后台管理也独立存一份，这种场景是由于对查询性能要求高产生的，所以必须要冗余，在业务的取舍上，肯定是对让用户更快看到信息，那么不可避免的是带来维护成本的增加，对于数据一致性问题，只要做到最终一致就可以了，分布式的CAP原则的实际应用基本都是通过牺牲数据一致性(C)来保证高可用(A)和高可靠(P)， 因为这种场景大部分都是可以接受短暂的数据不一致的，对业务的影响及其微小。
又比如，”用户昵称”字段”nickname”本来属于表”user”，那么，表示”用户昵称”的字段就唯一的只应该属于”user”表的”nickname”字段，这样，当用户要修改昵称的时候，程序就只需要修改 user.nickname这个字段就行了。不过问题也随之而来，我在其他数据表(如订单orders表)里只存储了用户的ID，我要通过这个ID值得到用户昵称该怎么办呢？一个普遍的解决方法是通过联接(join)，在查询时，通过id这个唯一条件联接两个表，从而取到用户的昵称。
这样确实是没问题，我也一直觉得这样是最好的方案，扩展方便，当要更新用户信息时，程序中要修改的地方很少，但是随着数据库里数据不断增加，百万，千万，同时，用户表的数据肯定也在不断的增加的，它可能是十万，百万。这个时候，你会发现两个表通过联接来取数据就显得相当费力了，可能你只需要取一个nickname这个用户昵称属性，你就不得不去联一下那个已经几十万的用户表进行检索，其速度可想而知了。
这个时候，你可以尝试把nickname这个字段加到orders这个订单表中，这样做的好事是，当你要通过订单表呈现一个订单列表时，涉及用户的部分可能就不需要再进行联接查询了。当然，有利就有弊，这样做的弊端就是，当你尝试更新用户信息时，你必须记得用户信息表里当前被更新的字段中，有哪些是冗余字段，分别属于哪些表，找到他们，然后加入到你的更新程序段中来。这个是程序中的开销，开销在开发人员的时间上了。至于这样做是否值得，就得看具体情况而定了。
所以，目前要创建一个关系型数据库设计，我们有两种选择：
1，尽量遵循范式理论的规约，尽可能少的冗余字段，让数据库设计看起来精致、优雅、让人心醉。
2，合理的加入冗余字段这个润滑剂，减少join，让数据库执行性能更高更快。
选择哪一种呢？如果你是一个美学狂人，并且财大气粗，非要使用第一种方案，也没关系，这种方案的短板并非不可救药的。比如，你可以增加服务器，从数据库集群入手，进行读写分离，读的时候可以将压力分散到不同的数据库服务器上，这样也可以获得很好的性能，只是多付出了硬件成本和维护成本。或者，你可以在数据库前端架设Memcached之类的缓存服务，减少读写数据库的次数，也可以达到同样的效果。问题在于你确定你需要缓存之类的东西。
如果做不到上面的只能选择第二种了，当涉及到修改的时候就需要将所有相关的数据进行修改了。