日常工作中 经常看到有人设计表结构的时候 喜欢冗余字段 比如 订单表 里面 有用户ID 然后再把用户名称冗余进去。大部分场景下用户都会被缓存,取订单时根据ID 再去缓存拉一下用户 是否更合理,另外类似于这种被join的表字段(用户名称)冗余后 不会做为查询条件情况是否都没有任何意义?
要分清楚场景,有些是属于快照,有些是属于冗余。
1.快照场景:交易场景大部分是数据快照,而不是冗余,用户下单时候的用户名、地址、商品名称、商品描述等,若采用关联,商品在下单后发生了更新的话再去关联查询就会导致和用户操作时的数据不一致,从而产生纠纷。
2.冗余场景:一般数据改动的可能性少,而查询多的场景会使用冗余,例如淘宝的店铺名称,淘宝商家中心会有这个字段,可能里面的商家论坛也有,再假设聚划算这种独立的大业务自己也存一份,再来个垂直频道电器城的后台管理也独立存一份,这种场景是由于对查询性能要求高产生的,所以必须要冗余,在业务的取舍上,肯定是对让用户更快看到信息,那么不可避免的是带来维护成本的增加,对于数据一致性问题,只要做到最终一致就可以了,分布式的CAP原则的实际应用基本都是通过牺牲数据一致性(C)来保证高可用(A)和高可靠(P), 因为这种场景大部分都是可以接受短暂的数据不一致的,对业务的影响及其微小。
ps:例子可能举得不是很恰当,自己意会- -!
作者:GongNation
链接:https://www.zhihu.com/question/50662784/answer/147731726
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
「三年博客,如果觉得我的文章对您有用,请帮助本站成长」
共有 0 - 数据库设计冗余和快照