1.什么是冗余字段？
在设计数据库时，某一字段属于一个表，但它又同时出现在另一个或多个表，且完全等同于它在其本来所属表的意义表示，那么这个字段就是一个冗余字段，外键除外
——以上是我自己给出的定义
2.冗余字段应用场景
冗余字段的存在到底是好还是坏呢？这是一个不好说的问题。可能在有人看来，这是一个很蹩脚的数据库设计。因为在数据库设计领域，有一个被大家必须遵守的数据库设计范式，这个范式理论上要求数据库设计逻辑清晰、关系明确，比如，”用户昵称”字段”username”本来属于表”user”，那么，表示”用户昵称”的字段就唯一的只应该属于”user”表的”username”字段，这样，当用户要修改昵称的时候，程序就只需要修改 user.username这个字段就行了，瞧，很方便。不过问题也随之而来，我在其他数据表(如订单orders表)里只存储了用户的ID，我要通过这个ID值得到用户昵称该怎么办呢？一个普遍的解决方法是通过联接(join)，在查询时，通过id这个唯一条件联接两个表，从而取到用户的昵称。还有就是通过用户昵称筛选订单，也是需要join查询
这样确实是没问题，我也一直觉得这样是最好的方案，扩展方便，当要更新用户信息时，程序中要修改的地方很少，但是随着数据库里数据不断增加，百万，千万，同时，用户表的数据肯定也在不断的增加的，它可能是十万，百万。这个时候，你会发现两个表通过联接来取数据就显得相当费力了，可能你只需要取一个username这个用户昵称属性，你就不得不去联一下那个已经几十万的用户表进行检索，其速度可想而知了。
这个时候，你可以尝试把username这个字段加到orders这个订单表中，这样做的好事是，当你要通过订单表呈现一个订单列表时，涉及用户的部分可能就不需要再进行联接查询了。当然，有利就有弊，这样做的弊端就是，当你尝试更新用户信息时，你必须记得用户信息表里当前被更新的字段中，有哪些是冗余字段，分别属于哪些表，找到他们，然后加入到你的更新程序段中来。这个是程序中的开销，开销在开发人员的时间上了。至于这样做是否值得，就得看具体情况而定了。
所以，目前要创建一个关系型数据库设计，我们有两种选择：
1.尽量遵循范式理论的规约，尽可能少的冗余字段，让数据库设计看起来精致、优雅、让人心醉。
2.合理的加入冗余字段这个润滑剂，减少join，让数据库执行性能更高更快。
选择哪一种呢？ 根据自己的实际业务需求