关于数据库设计中字段冗余取舍的问题

铂金小猪 发布于 2015/04/24 08:29
阅读 4K+
收藏 1

目前在用Discuz!3.2给人做一个东西,需要增加很多自定义字段,其中涉及到要和其他帖子产生关联。详情如下:
A栏目名称是“品牌”,B栏目的名称是“商品”,现在商品栏目中新增的帖子,需要选择一个“品牌”的帖子做为自己的“品牌”。(这不是一个商城,用dz来做肯定是有特殊情况,所以就不要提商城的事儿。)dz中每一个帖子都有一个fid字段和一个name字段,在这个选择“品牌”的过程中,考虑到以后访问量等因素,我应该在“商品”添加的时候同时添加fid和name到“商品”附表,这样系统查询的时候就一并查询出来;还是只添加fid,然后在需要显示name的时候,再次向数据库查询fid?有4个地方需要在展示"商品"帖子的时候显示"品牌"帖子的name。

对于高并发访问的数据库设计完全没得概念,所以还请各位DB大牛不吝赐教。谢谢啦。

---------------补充----------

总结来说就是,冗余两个字段,每个字段的长度在10个字符串以内。但是可以一次性查询出来,不冗余这两个字段,则需要第二次查询。考虑到高并发等情况,我该怎么选择?

----------------再次补充-------------------
经过和朋友讨论以后,在基于DZ框架的背景下,最终还是采取冗余的方法,考虑到初期数据量并不是非常大,冗余,对于数据库的影响不大,可以节省很多开发时间,直接使用DZ自带的方法就可以查询到内容,就无需再次修改PHP。后期数据量非常大的时候,再来删除冗余字段,或者做其他更规范的数据库处理。

加载中
0
刘同岳
刘同岳

如果name不经常变的情况下,且关联name处很多。可以冗余存储下字段。

否则就只记录关系标识即可。

刘同岳
刘同岳
回复 @铂金小猪 : 所以为刚才问你name会变吗?如果会变的情况下就不冗余,有可能多个商品会关联一个品牌,这样依赖性太强。不会变的情况下再冗余。
铂金小猪
铂金小猪
回复 @刘同岳 : 主要是考虑到品牌表name如果有改动,那涉及到的商品表就有个同步的问题。
刘同岳
刘同岳
@铂金小猪 那就冗余name字段就可以。
铂金小猪
铂金小猪
回复 @刘同岳 : name不会改变。
刘同岳
刘同岳
@铂金小猪 前提是name不变,只需要name字段时,那就冗余。
下一页
0
一心二影
一心二影
冗余两个字段吧,查询方便很多。业余人士
0
方棱
方棱

即,表A中有指向表B的外键字段,那表A中是否应该再增加表B的常用字段(如标题),以减少Join。

我的做法是:不用。

在数据量没达到十万级别的时候,这样基本没问题。

如果数据量和并发数都上来后,也不会变动A或者B,而是会在前面加一个ETL层,其中有Join好的AB(可以是数据库,也可以是别的缓存层)。ETL层和数据库层之间用MQ打通数据同步机制。

铂金小猪
铂金小猪
多谢,但感觉这种的话需要做的修改会很多。
0
子矜
子矜

引用来自“方棱”的评论

即,表A中有指向表B的外键字段,那表A中是否应该再增加表B的常用字段(如标题),以减少Join。

我的做法是:不用。

在数据量没达到十万级别的时候,这样基本没问题。

如果数据量和并发数都上来后,也不会变动A或者B,而是会在前面加一个ETL层,其中有Join好的AB(可以是数据库,也可以是别的缓存层)。ETL层和数据库层之间用MQ打通数据同步机制。

我觉得从数据库设计范式来看 冗余字段是不可取的。然后对于联表查询,应该创建视图。不过大并发下,肯定得用缓存了,用MQ如何打通缓存?每次进行数据库操作的时候,同时提交一个信息到MQ队列去么?
铂金小猪
铂金小猪
主要还得考虑dz的程序固有的架构。
0
k
kakaximu
以人为本,方便查询
0
魔力猫
魔力猫

使用DZ开发是否合适先不考虑。

对应数据库设计,我只说一个原则,那就是除非你真的有足够证据证明按照规范范式设计数据库会有性能问题而且这个性能问题无法解决,或者有足够证据证明你写入的数据是永远不会被修改的,否则不要轻易用性能作为借口反范式设计。

随便拿数据库表当excel用,有可能引发的问题远远超过所谓少连接一个表剩下的东西。

数据库对于表连接的处理能力其实非常强大,关联几个十几个表,只要数据库结构设计合理,其实是非常轻松的事情。

铂金小猪
铂金小猪
回复 @魔力猫 : 嗯,就是考虑这个设计明显是不科学的,所以才会来向各位请教。我现在的想法是先折中,用冗余先把功能做出来,如果他们频繁出现已经发布商品了还再修改品牌名称的情况,那就果断删除,冗余字段,采用二次查询的方法。因为DZ的架构原因,修改起来比较麻烦。不过你说的我会记下的,重点测试一下。冗余这个方法也是折中的一个做法。
魔力猫
魔力猫
回复 @铂金小猪 : 我不是说选择DZ正确还是错误。我的意思是这方面我不予以评价,仅仅是对额外自定义数据库设计方面进行讨论。 除非你真的确认这部分消耗了太多的性能,而且无法通过其他方式弥补,或者真的是永远不会改变的只读属性,不然不要轻易使用反范式设计,你必须知道你在做什么,这是一个超危险的决定,一旦数据库设计出问题修改成本很大,而符合规范的数据库总比不规范的数据库好改。
铂金小猪
铂金小猪
程序是要考虑dz的,而不是不考虑。我们选用dz,肯定是有我们的原因。如果不需要考虑dz,我也不会问这个问题了。因为我也不喜欢dz,但市面上确实没有比dz更合适我的了
铂金小猪
铂金小猪
前提是得考虑dz的架构,如果是自己设计这些都不是问题。而且不是用性能来做借口啊,现在就只有两条路,要么就是只存fid,然后前台显示的时候再查询name,要么就是保存name,由dz查询出来直接前端显示。
返回顶部
顶部