精华内容
下载资源
问答
  • 数据库冗余字段

    2019-07-09 17:43:01
    在设计数据库时,某一字段属于一个表,但它又同时出现在另一个或多个表,且完全等同于它在其本来所属表的意义表示,那么这个字段就是一个冗余字段。 ——以上是我自己给出的定义 冗余字段的存在到底是好还是坏呢?...

    什么是冗余字段?

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

    ——以上是我自己给出的定义

    冗余字段的存在到底是好还是坏呢?这是一个不好说的问题。可能在有人看来,这是一个很蹩脚的数据库设计。因为在数据库设计领域,有一个被大家奉为圭臬的数据库设计范式,这个范式理论上要求数据库设计逻辑清晰、关系明确,比如,”用户昵称”字段”nickname”本来属于表”user”,那么,表示”用户昵称”的字段就唯一的只应该属于”user”表的”nickname”字段,这样,当用户要修改昵称的时候,程序就只需要修改 user.nickname这个字段就行了,瞧,很方便。不过问题也随之而来,我在其他数据表(如订单orders表)里只存储了用户的ID,我要通过这个ID值得到用户昵称该怎么办呢?一个普遍的解决方法是通过联接(join),在查询时,通过id这个唯一条件联接两个表,从而取到用户的昵称。

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

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

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

    1. 尽量遵循范式理论的规约,尽可能少的冗余字段,让数据库设计看起来精致、优雅、让人心醉。
    2. 合理的加入冗余字段这个润滑剂,减少join,让数据库执行性能更高更快。

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

    当然,如果你跟我一样,只有一台每月几十元买来的vps,甚至可能是一个虚拟主机,建议还是暂时压制你的美学欲望,跟我一起选择第二种方案吧,除非你愿意你的整个数据库都一直只有零零星星的几条数据

    展开全文
  • 今天小编就为大家分享一篇关于如何合理使用数据库冗余字段的方法,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
  • 关于数据库冗余字段设计的利与弊

    千次阅读 2020-03-16 14:37:18
    因为近期完全是我负责某项目开发,所以关于数据库冗余字段的设计,有了一些新的见解。 其实在数据库设计方面,对于冗余字段的设计,网上也是褒贬不一的。通过资料的查询,大致有以下两个方向: 1、支持冗余字段的...

    前言:该文章仅为作者个人的感悟,仅供参考,欢迎大家做技术讨论,谢谢。

    因为近期完全是我负责某项目开发,所以关于数据库冗余字段的设计,有了一些新的见解。

    其实在数据库设计方面,对于冗余字段的设计,网上也是褒贬不一的。通过资料的查询,大致有以下两个方向:

    1、支持冗余字段的设计

    引入冗余字段的设计,能够减少表关联,使用SQL查询的时候执行效率更快,特别是在数据量比较大的情况下。

    2、否定冗余字段的设计

    主要是违反了数据库三范式的,数据库设计看着不那么赏心悦目。

     

    本人本着好看不如好用的思想,采纳了第一种,引入了部分冗余字段作为尝试,下面是我实际项目中遇到的真实尴尬情况。

    1、运用冗余字段存储主表的信息,遇见主表数据更新,带冗余字段的表该怎么办?

    例如:客户产品订购表,想不关联客户表查询客户名称,因此把客户名称存入产品订购表的冗余字段,当这个客户名称修改的时候,难道还要同步更新这张表么。如果客户名称并不是指冗余在这一张表,还有其他N张表都设计为客户名称为冗余字段,那么这个问题就比较严重了。

    个人总结:冗余字段的设计还是尽量选取一些几乎不会发生修改的字段,以免造成尴尬情景。

    2、使用冗余字段是真的为了查询速度吗?

    本人使用冗余字段的原因,高效的执行效率只是其中一点,最主要的是为了单表查询(主要还是懒啊)。所以,引入冗余字段确实得慎重,不要为了节省那几行代码的时间,留下这么大的隐患。

     

    2020.4.2

    今天突然想起,有种情况一定要用冗余字段。举个例子:你昨天买了个手机,那么交易记录表里面就会新增一条记录,数据库里的记录可能是这样的,ID、购买人、商品编号、购物时间...,类似于这种情况,就应该加个商品名称的字段,否则第二天就把商品编号对应的物品调整成了鸡蛋,客户在查询的时候,就会发现自己花了几千块买了个鸡蛋。。。

    以上只是举个例子,当然实际情况交易记录表肯定不是这么去设计的。

    展开全文
  • 关于数据库冗余字段

    千次阅读 2011-10-13 14:25:30
    关于数据库冗余字段 2011-10-13 星期四 阴雨 原则: 1. 不要随便作冗余! 2. 冗余的字段千万不要随便暴露出去! 3. 要冗余也要冗余有业务关系的字段! 最后一点——还是不要随便作冗余! 冗余就...
    
    

    关于数据库冗余字段

    2011-10-13 星期四 阴雨

    原则:
    1. 不要随便作冗余!
    2. 冗余的字段千万不要随便暴露出去!
    3. 要冗余也要冗余有业务关系的字段!
    最后一点——还是不要随便作冗余!

    冗余就像缓存,对于只读字段,那么冗余是没有问题的。但是如果这个字段是会被更新的,那么冗余就有可能带来更新的性能下降,和不一致的情况。特别是如果冗余在一个大表中,这带来的压力是非常大的。一个具体例子就是我们产品表和BuyOffer表中的create_type和is_validate字段的冗余。这两个字段其实是冗余自vaccount表的stage和status。目的是为了避免关联vaccount表来获取这两个字段的信息。但是它绝对是一个失败的冗余。首先:
    1. 冗余不完全:vaccount表最重要的三个字段:service_type,stage和status。这里只冗余了stage和status,而忽略了service_type,这导致其实在95%场景下都是需要根据product表中的company_id多查询一下vaccount表。
    2. 冗余在大表:vaccount是一个小表,根据主键关联或者查询并不会带来多大的性能消耗,而product是一张大表,这导致在CRM拉上拉下一个会员的时候,更新vaccount的同时,也需要更新product和buy_offer表的这两个冗余字段。这就带来了很大的数据库压力。再加上我们现在前后台分库之后,给数据库同步也带来了很大的压力(国际站还有特有的中美同步),还有复杂的补偿逻辑。而在业务逻辑上,本来拉上拉下一个会员,从业务上应该与这个会员的产品和buyOffer一点关系都没有。现在,由于这两个字段的冗余,导致了这个会员拥有的产品、Offer、Column等都需要牵扯进来。
    3. 冗余字段与product没有直接的业务关系:将一个业务模型的关键字段冗余到另一个业务模型上,并且在上层DO中暴露出来,这明显是混淆了业务模型。因为将冗余字段放在productDO中,明显就是认为isValidate和createType是product的一个属性,而不会认为它是一个vaccount的冗余字段。所以如果要合理的话,应该将这两个冗余字段放在productDO的一个Vaccount属性中,而不是散落在productDO中。这就是业务模型和数据库模型的区别。

    另一个例子是company表的is_pass_av字段,这个字段比product的isValidate和createType字段冗余有意义的多,因为是否通过AV认证确实就是公司的一个属性,将这个属性放在业务模型中是绝对没有问题的。但是为什么还是说他是一个冗余字段呢?因为在数据库层面上,这个字段的值是由诚信团队回填到company表的,也就是说它是来自于AV相关的表。由于是回填,所以也会出现不一致的现象,不过由于company和AV认证表是一对一的关系,所以没有前面提高的更新压力情况。也就是说isPassAV属性放在company业务模型是正确的,但是是否要对应在数据库模型中,也就是company表,是有待商榷的。

    补记:2011-6-13

    这两个冗余字段,除了带来很高的数据库和同步压力,以及巨大的维护成本之外,还容易导致问题。

    周末小强打电话给王小雪,说数据库load很高,锁表严重。小雪和我一起查看了log日志,发现同一家公司的所有产品在同一个时间相续被更新了多次(大概相隔3秒做一次),就周末两天大概就有10多家公司被拉下,其中有家公司有3万多条产品。原因应该是分久必合项目将本地接口改成dubbo远程服务,而默认超时时间太短,导致超时抛出异常,dubbo或者后面的业务代码(具体是哪个麻烦李鼎和王兴勇帮忙查找一下)进行了重试导致。


    再补记2011-7-15:

    后来,本人实在看不下去了,将这两个冗余字段下线了(前后花了一年多的时间,背了一个B类和C类故障。。),整个世界清静很多。

    展开全文
  • 在设计数据库时,某一字段属于一个表,但它又同时出现在另一个或多个表,且完全等同于它在其本来所属表的意义表示,那么这个字段就是一个冗余字段。 2.冗余字段应用场景 冗余字段的存在到底是好还是坏呢?这是一个...

    原文链接:https://blog.csdn.net/z15818264727/article/details/79628200

    1.什么是冗余字段?

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

    2.冗余字段应用场景

    冗余字段的存在到底是好还是坏呢?这是一个不好说的问题。可能在有人看来,这是一个很蹩脚的数据库设计。因为在数据库设计领域,有一个被大家必须遵守的数据库设计范式,这个范式理论上要求数据库设计逻辑清晰、关系明确,比如,”用户昵称”字段”username”本来属于表”user”,那么,表示”用户昵称”的字段就唯一的只应该属于”user”表的”username”字段,这样,当用户要修改昵称的时候,程序就只需要修改 user.username这个字段就行了,瞧,很方便。不过问题也随之而来,我在其他数据表(如订单orders表)里只存储了用户的ID,我要通过这个ID值得到用户昵称该怎么办呢?一个普遍的解决方法是通过联接(join),在查询时,通过id这个唯一条件联接两个表,从而取到用户的昵称。还有就是通过用户昵称筛选订单,也是需要join查询

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

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

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

    1.尽量遵循范式理论的规约,尽可能少的冗余字段,让数据库设计看起来精致、优雅、让人心醉。
    2.合理的加入冗余字段这个润滑剂,减少join,让数据库执行性能更高更快。
    选择哪一种呢? 根据自己的实际业务需求

    展开全文
  • 数据库冗余字段解决思路

    千次阅读 2019-10-25 18:24:56
    保证业务情况下前期收集整理数据统计痛点开发自查冗余字段上报中期确认不再维护字段并且整理对应代码平滑剔除字段后期删除字段与培训平滑剔除三个月后对字段进行删除维护共有的表结构介绍wiki 前期收集整理 数据统计...
  • 最近在做一个新的小功能,设计了几个表,在...冗余字段虽然叫冗余,基于数据库结构设计的第三范式,冗余字段是不可以出现的,会使数据库出现多余的数据。但是在实际的工作过程中,冗余字段是可以出现的。多表的关...
  • 数据库冗余字段的理解。

    千次阅读 2017-08-21 20:12:47
    最近在做一个新的小功能,设计了几个表,...冗余字段虽然叫冗余,基于数据库结构设计的第三范式,冗余字段是不可以出现的,会使数据库出现多余的数据。但是在实际的工作过程中,冗余字段是可以出现的。多表的关联查询,
  • 我们需要隐藏,因为我们不需要privot,而且pritvot也不在我们模型本身,他是中间数据另外冗余字段,我们有一个表是记录图片的,另一个表是记录商品的。我们可以在图片你放商品图片里的url同时商品里放图片id和图片...
  • 依个人理解,冗余字段就是本存在一张表的字段,也出现在另一张表中。 例如:有三张表,用户表、商品表、订单表,用户表中有字段name,而订单表中也存在字段name。 对于这个字段冗余有好有坏 好: 从用户表、商品...
  • 数据库冗余字段

    2021-03-02 14:06:57
    如果参照三范式,那我们在设计数据库的时候就必须致力于消灭冗余字段,毕竟如果我们需要更新某条记录,而这条记录又恰好包含了冗余字段,那么我就必须更新所有携有冗余字段的表。如果冗余冗余字段只出现在很少的表中...
  • 数据库设计冗余字段

    2017-01-05 16:49:54
    冗余字段的个人理解: table1 id name other table2_id table2 id name phone email   当table1 中的 table2_id 关联的是table2 中的id 如果table1 想要根据table2_id 来获取 table2 的name 字段 可以 连接查询...
  • 数据库建立冗余字段的原则

    千次阅读 2018-02-13 17:45:09
    数据库model设计,致力于不要建立冗余字段。因为维持数据一致性是一个big problem。 但是作为操作日志,记录,历史这些,是需要冗余的。其实,在这里已经不是冗余了,只是记录了当时的信息。 比如下面的operator_n.....
  • 数据库冗余字段的作用

    千次阅读 2016-12-09 23:40:30
    按照第三范式的要求,是不应该存在冗余字段的,但现在我改变了看法,认为冗余字段非常有必要。 例如: 在订单表中,‘客户名称’字段就是冗余字段,加了这个字段,就需要在客户信息表修改(客户名称改变)的时候...
  • 数据库中的冗余字段

    2019-11-14 15:17:58
    在建库的时候,尤其是复杂的数据库,难免会出现大量的冗余字段,出现数据冗余 数据冗余:在一个数据集合中重复的数据称为数据冗余. 数据冗余的目的: 数据的应用中为了某种目的采取数据冗余方式。 1、重复...
  • 在设计数据库时,某一字段属于一个表,但它又同时出现在另一个或多个表,且完全等同于它在其本来所属表的意义表示,那么这个字段就是一个冗余字段。 ——以上是我自己给出的定义 冗余字段的存在到底是好还是坏呢...
  • 数据库中有3个表(A,B,C)其中A中的数据最少2万条左右,B的数据比较多10万条左右,而C表数据最多100万左右,其中查看B表和C表时都要根据id获取A表中的地市名称,这种情况下要怎么加冗余字段,如果在B和C表中加上A...
  • 在设计数据库时,某一字段属于一个表,但它又同时出现在另一个或多个表,且完全等同于它在其本来所属表的意义表示,那么这个字段就是一个冗余字段。 加深理解 在设计数据库的时候,应该注意一下什么呢?首先来看...
  • 数据库设计之冗余字段

    千次阅读 2017-12-21 14:19:15
    数据设计,冗余
  • 数据库---冗余字段

    千次阅读 2014-03-17 17:05:22
    在设计数据库时,某一字段属于一个表,但它又同时出现在另一个或多个表,且完全等同于它在其本来所属表的意义表示,那么这个字段就是一个冗余字段。 ——以上是我自己给出的定义 冗余字段的存在到底是好还是坏呢...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,902
精华内容 760
关键字:

数据库冗余字段