数据库冗余是否必要

数据库冗余是否必要

三丰 soft张三丰

咱们在这里假设 认为遵照数据库设计的范式，不要冗余 的为正方：认为设计数据库设计须要设计一些适当冗余的为 反方：

但愿你们能结合本身设计经验，展开积极的讨论：

下面是我举的一个例子：

好比作一个单据表，主要字段 单号 商品编号 商品名称 单价 数量

正方：单据表只能有“ 单号 商品编号 单价 数量 ”这几个字段， 没有“商品名称 ”这个字段，要显示这个信息，就须要和 “商品基本信息表” 关联获取；

反方：

若是 这里的“商品基本信息表 ”里若是有100万条记录，那么我每作一个单据，单据明细信息都须要经过和100万条记录的“商品基本信息表 ”关联，显然，这样软件运行效率确定要受到影响。

并且 ，写sql语句只关联一个表总比关联多个表更方便。

正方：

若是客户在使用过程当中，商品名称发生了改变，那么那些历史单据上的商品名称就会跟着变化，这样能保证数据的一致性；不然，数据在统计的时候，明明是一个商品的入库状况，就会被当成两个或多个，月末结算的时候就会有问题。

反方：一、“商品基本信息表 ”的“商品名称”原本就不容许轻易改变。若是该商品参与了单据处理，“商品名称”就不该该修改。二、若是“商品名称”修改了，那么修改前和修改后的单据对于同一个“商品编号”原本就应该显示不一样的“商品名称”；就像一我的，若是他在50岁之后该名字的话，那么它50岁前做的事情，咱们也应该用他的原名啊。 三、若是正方认为“商品名称”能够修改，那么“商品编号”也能够修改喽。可是 你是经过“商品基本信息表 ”的“商品编号”做为关联的。“商品编号”一旦修改，那么单据明细因为找不到之前的“商品编号”，记录就会丢失。这不是出大乱子。固然，你会说“商品编号”是商品信息的惟一识别；可是，为何不能把“商品名称”最为惟一识别呢。咱们不防看看用户更改“商品名称”的缘由是什么？其实 “商品名称” 每每是相对固定，而“商品编号”反而会由于当初的是设计不合理，而作更改；好比，一个中学生，他原本的编号是35 ，后来学校改革。把他的编号该成 9831 他的编号变了，可是他的名字却不会变。若是我用冗余，就不会影响该学生在学校食堂的消费历史纪录；

正方：若是按照反方的观点，为什么须要“商品编号”，不如在“商品信息表”里就有一个“商品名称”不就完了；中学生，也不用学号，直接用姓名识别。首先，“商品编号”或“学生学号”是有意义的。最简单的，“商品名称”或“学生姓名”可能重复；可是利用编号就能容易识别；若是用户须要更改编号，那么咱们能够在每一个表里作个内部的id字段，该字段自增加，各个表须要关联时，都是经过他们的id来关联。这样即便修改了编号也无所谓。

反方：使用内部id的方法，会大大加大软件的代码编写的复杂度。尤为是报表系统里，为了获取某个特定的信息会写出很复杂的sql,就算你用视图，道理也是同样的，由于写视图也很费力。并且有时复杂的视图的错误隐藏的很深。再说，好比那个中学生从初一上到高三，忽然老师那天不当心把他的学号和姓名都修改了，那么那些在食堂里消费的历史纪录相应的信息修改了。结果想还原都没有办法。若是咱们用冗余，就不存在这个问题。

+++++++++++++++++++++++++++++++++++++++++++++++

数据库冗余：存储两倍数据，冗余可使系统速度更快。（减小联查）

我的理解：

在设计数据库时，某一字段属于一个表，但它又同时出如今另外一个或多个表，且彻底等同于它在其原本所属表的意义表示，那么这个字段就是一个冗余字段。

至于冗余字段的存在究竟是好仍是坏呢？

这是一个很差说的问题。可能在有人看来，这是一个很蹩脚的数据库设计。由于在数据库设计领域，有一个被你们奉为圭臬的数据库设计范式，这个范式理论上要求数据库设计逻辑清晰、关系明确。

好比，”用户昵称”字段”nickname”原本属于表”user”，那么，表示”用户昵称”的字段就惟一的只应该属于”user”表的”nickname”字段，这样，当用户要修改昵称的时候，程序就只须要修改 user.nickname这个字段就好了，瞧，很方便。不过问题也随之而来，我在其余数据表(如订单orders表)里只存储了用户的ID，我要经过这个ID值获得用户昵称该怎么办呢？一个广泛的解决方法是经过联接(join)，在查询时，经过id这个惟一条件联接两个表，从而取到用户的昵称。

这样确实是没问题，我也一直以为这样是最好的方案，扩展方便，当要更新用户信息时，程序中要修改的地方不多，可是随着数据库里数据不断增长，百万，千万，同时，用户表的数据确定也在不断的增长的，它多是十万，百万。这个时候，你会发现两个表经过联接来取数据就显得至关费力了，可能你只须要取一个nickname这个用户昵称属性，你就不得不去联一下那个已经几十万的用户表进行检索，其速度可想而知了。

这个时候，你能够尝试把nickname这个字段加到orders这个订单表中，这样作的好事是，当你要经过订单表呈现一个订单列表时，涉及用户的部分可能就不须要再进行联接查询了。固然，有利就有弊，这样作的弊端就是，当你尝试更新用户信息时，你必须记得用户信息表里当前被更新的字段中，有哪些是冗余字段，分别属于哪些表，找到他们，而后加入到你的更新程序段中来。这个是程序中的开销，开销在开发人员的时间上了。至于这样作是否值得，就得看具体状况而定了。

因此，目前要建立一个关系型数据库设计，咱们有两种选择：

1，尽可能遵循范式理论的规约，尽量少的冗余字段，让数据库设计看起来精致、优雅、让人心醉。

2，合理的加入冗余字段这个润滑剂，减小join，让数据库执行性能更高更快。

选择哪种呢？若是你是一个美学狂人，而且财大气粗，非要使用第一种方案，也不要紧，这种方案的短板并不是不可救药的。好比，你能够增长服务器，从数据库集群入手，进行读写分离，读的时候能够将压力分散到不一样的数据库服务器上，这样也能够得到很好的性能，只是多付出了硬件成本和维护成本。或者，你能够在数据库前端架设Memcached之类的缓存服务，减小读写数据库的次数，也能够达到一样的效果。问题在于你肯定你须要缓存之类的东西。

若是作不到上面的只能选择第二种了，当涉及到修改的时候就须要将全部相关的数据进行修改了。

空间换取时间，到底值不值得，看业务需求与取舍了。