关于数据库冗余字段及适当性

依个人理解,冗余字段就是本存在一张表的字段,也出现在另一张表中。

例如:有三张表,用户表、商品表、订单表,用户表中有字段name,而订单表中也存在字段name。

对于这个字段冗余有好有坏

好:

从用户表、商品表、订单表说起,当我需要查询“订单表”所有数据并且只需要“用户表”的name,一般都可以通过数据库连接(join)查询,

例如“商品表”存在字段-->用户的id,“订单表”存在字段-->商品的id,我可以查询所有订单,通过订单中商品id查询对应商品,然后对应查询用户name,

如果当表多起来时,例如1000张表(“有点夸大了,请谅解”),为了得个用户表中的name,这查询的速度就可想而知了。

这时给订单表加个字段name,则直接查询该订单就完成了需求,简单明了。

不好:

同上,这时候对用户name字段增删改,对应也要对订单表中的字段增删改,这时还要去了解所有表中的冗余字段,以防有些表中的字段没对应修改。

针对这种情况,看需求,如果影响不大,利于开发效率,可适当的增加冗余字段。

注意:这是小白第一次写博客,有些举例有点不符合实际开发,望大牛们谅解。

版权声明:本文为不会代码的小白原创文章,未经允许不得转载。

时间: 2024-10-13 07:37:57

关于数据库冗余字段及适当性的相关文章

数据库冗余字段思考

根据数据库设计的第三方式,在数据库设计过程中,应该尽量消除冗余.即设计数据库时,某一个字段属于一张表,但它同时出现在另一个或多个表,且完全等同于它在其本来所属表的意义表示,那么这个字段就是一个冗余字段. 随着企业数据量与并发量不断的增加,冗余字段的存在到底是好还是坏呢? 根据第三范式而言,冗余字段是垃圾的数据库设计. 2.举例说明与研究 所有问题出现必然因为场景问题,针对冗余字段问题,分为两个场景: (1)快照场景(副本场景):交易场景大部分是数据快照,而不是冗余,用户下单时候的用户名.地址.商

数据库中的历史数据和冗余字段

根据实际的业务需求,许多数据需要永久的保存,并且不随之后的一个数据的改变而影响其他数据,举一个例子,电商系统中的订单,订单中包括你买的商品A价格100,n天后A可能价格下降至90,那么你订单价格会是90吗?怎么解决?我的答案是:直接在订单表里加入价格字段,每次生成订单记录时都写入价格即可.我觉得如果类似"价格"这种字段如果太多的话,可以考虑新建一个存放历史记录表.需要注意,这里的"价格"并不是我们在进行数据库设计时的所谓冗余字段.冗余字段说的为了系统的查询效率而牺牲

数据库设计之冗余字段设计

在设计数据库时,某一字段属于一个表,但它又同时出现在另一个或多个表,且完全等同于它在其本来所属表的意义表示,那么这个字段就是一个冗余字段. --以上是我自己给出的定义 冗余字段的存在到底是好还是坏呢( 冗余是为了效率,减少join.单表查询比关联查询速度要快.某个访问频繁的字段可以冗余存放在两张表里,不用关联了. )?这是一个不好说的问题.可能在有人看来,这是一个很蹩脚的数据库设计.因为在数据库设计领域,有一个被大家奉为圭臬的数据库设计范式,这个范式理论上要求数据库设计逻辑清晰.关系明确,比如,

2019-3-1 09:05:16数据库建立的三种范式及冗余字段

第一范式(1NF)无重复的列 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性.如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系.在第一范式(1NF)中表的每一行只包含一个实例的信息.简而言之,第一范式就是无重复的列. 1NF的定义为:符合1NF的关系中的每个属性都不可再分 下表所示情况,便不符合1NF的要求: 说明:在任何一个关系数据库中,第一范式

数据库的字段设计的几个心得

数据库的字段设计有很多细节性的技巧,下面将过去在开发中体会到经验整理出来,做个备忘. tinyint 是-128到128 .当属性设置为unsigned的时候.最大值就是255了.现在知道为什么需要设置为unsigned属性了.原来是为了最大限度的使用给予的存储空间.如果不设置.那么假如你的值都是正数的.那么-128这一百多个数字就相当于是浪费了.澳门葡京赌场是真的吗 tinyint会自动设置为tinyint(3). smallint 不设置unsigned的时候,也有3万多的样子. tinyt

数据库范式?编辑 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。

数据库范式 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小. 目前关系数据库有六种范式:第一范式(1NF).第二范式(2NF).第三范式(3NF).巴斯-科德范式(BCNF).第四范式(4NF)和第五范式(5NF,还又称完美范式). 第一范式(1NF) 所谓第一范式(1NF)是指在关系模型中,对域添加的一个规范要求,所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,

关于数据库‘状态’字段设计的思考与实践

最近在做订单及支付相关的系统,在订单表的设计阶段,团队成员就‘订单状态’数据库字段设计有了一些分歧,网上也有不少关于这方面的思考和探讨,结合这些资料和项目的实际情况,拟对一些共性问题进行更深一层的思考,笔耕在此,和大家一起探讨. 问题综述 这里的分歧点即有团队内部的分歧点,也有网络上常见的一些分歧点,先将存在的分歧点抛出来: 1.订单表的‘订单状态’字段对应的字典值应当包含哪些状态值?对于‘已评论’.‘已退货’.’已退款’这类状态是放到‘订单状态’中?还是独立一个字段标识? 2.订单表的‘订单状

要不要冗余字段

这个问题我也遇到了,百度到这里却发现没有答案.这个问题我纠结了老长时间,至今仍未想明白.但是与其万马齐喑不如胡说八道.如果用户表添加计数字段,好处在于用空间换时间,查询速度肯定快多了:如果追求简洁无冗余,好处在于清晰易懂,写代码不蔓不枝,特别漂亮.如果用户表添加计数字段,坏处在于难以维护.当你添加一个粉丝关系的时候需要更新关注数和粉丝数,当你删除一个粉丝关系的时候也需要更新关注数和粉丝数.当你删除一个用户的时候,与他相关的所有粉丝关系.关注关系都要删除,相对应的粉丝数关注数也要删除,这个动作怎么

使用Python创建MySQL数据库实现字段动态增加以及动态的插入数据

应用场景: 我们需要设计一个数据库来保存多个文档中每个文档的关键字.假如我们每个文档字符都超过了1000,取其中出现频率最大的为我们的关键字. 假设每个文档的关键字都超过了300,每一个文件的0-299号存储的是我们的关键字.那我们要建这样一个数据库,手动输入这样的一个表是不现实的,我们只有通过程序来帮我实现这个重复枯燥的操作. 具体的示意图如下所示: 首先图1是我们的原始表格: 图1 这个时候我们需要程序来帮我们完成自动字段的创建和数据的插入. 图2 上图是我们整个表的概况.下面我们就用程序来