zoukankan      html  css  js  c++  java
  • 数据库冗余是否必要

    我们在这里假设  认为遵守数据库设计的范式,不要冗余  的为正方:
                    认为设计数据库设计需要设计一些适当冗余的为 反方:

    希望大家能结合自己设计经验,展开积极的讨论:

    下面是我举的一个例子:


     比如做一个单据表,主要字段
       单号  商品编号 商品名称 单价  数量


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

    反方:
     
    如果 这里的“商品基本信息表 ”里如果有100万条记录,那么我每做一个单据,单据明细信息都需要通过和100万条记录的“商品基本信息表 ”关联,显然,这样软件运行效率肯定要受到影响。



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

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

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

    正方:
     如果按照反方的观点,为何需要“商品编号”,不如在“商品信息表”里就有一个“商品名称”不就完了;中学生,也不用学号,直接用姓名识别。
    首先,“商品编号”或“学生学号”是有意义的。最简单的,“商品名称”或“学生姓名”可能重复;但是利用编号就能容易识别;
     如果用户需要更改编号,那么我们可以在每个表里做个内部的id字段,该字段自增长,各个表需要关联时,都是通过他们的id来关联。
    这样即使修改了编号也无所谓。

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

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

    数据库冗余:存储两倍数据,冗余可以使系统速度更快。(减少联查)

    个人理解:

    在设计数据库时,某一字段属于一个表,但它又同时出现在另一个或多个表,且完全等同于它在其本来所属表的意义表示,那么这个字段就是一个冗余字段。

    至于冗余字段的存在到底是好还是坏呢?

    这是一个不好说的问题。可能在有人看来,这是一个很蹩脚的数据库设计。因为在数据库设计领域,有一个被大家奉为圭臬的数据库设计范式,这个范式理论上要求数据库设计逻辑清晰、关系明确。

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

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

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

    所以,目前要创建一个关系型数据库设计,我们有两种选择:

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

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

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

    如果做不到上面的只能选择第二种了,当涉及到修改的时候就需要将所有相关的数据进行修改了。

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

  • 相关阅读:
    array and ram
    char as int
    pointer of 2d array and address
    Install SAP HANA EXPRESS on Google Cloud Platform
    Ubuntu remount hard drive
    Compile OpenSSL with Visual Studio 2019
    Install Jupyter notebook and tensorflow on Ubuntu 18.04
    Build OpenCV text(OCR) module on windows with Visual Studio 2019
    Reinstall VirtualBox 6.0 on Ubuntu 18.04
    Pitfall in std::vector<cv::Mat>
  • 原文地址:https://www.cnblogs.com/igoodful/p/10876505.html
Copyright © 2011-2022 走看看