一个微博数据库设计带来的简单思考

       转载请注明出处:http://blog.csdn.net/l1028386804/article/details/50441457

    在微博系统中,当前用户、关注者(也就是粉丝)、被关注者(崇拜对象)这三种角色是少不了的。他们之间看似简单的关系,但是其中数据库表将如何设计,却让我很难琢磨,在如下解决方案中,你们会选择哪种?为什么要选择这种?是否有更好的解决方案?

解决方案一:

表名

用户信息表

字段名

字段代码

字段类型

描述

用户名

User_id

Varchar(20)

主键

登陆密码

Password

Varchar(20)

 

……

……

……

 
    

表名

关注和被关注者表

字段名

字段代码

字段类型

描述

用户名

User_id

Varchar(20)

主键

关注者

Funs

Text

 

被关注者

Wasfuns

Text

 

    这是我最初想到的一种设计,这里“关注者”和“被关注者”都是采用拼接一些特殊字符分割存储的,比如A用户有只有关注者B、C、D、E,那么存入数据库关注者字段的数据将是B;C;D;E(暂且认为分割字符为;)。

基于上述方案,我提出一个问题:当这个用户的“关注者”或“被关注者”数量很大的情况下(比如10万个关注者)将是怎样的一串字符呢?而且当我们需要查询“关注者”或者“被关注者”最近的博客信息,将面临和博文信息表的一些时间排序查询,处理难度是要浪费性能的。

解决方案二:

    基于上述面临的问题,有人给我提供了一个扩展性的解决方案,同时也很好的解决了一个字段海量数据的问题。将方案一中的关注和被关注者表分解成两张表,如下:

表名

关注者表

字段名

字段代码

字段类型

描述

编号

Id

Number

主键

用户名

User_id

Varchar(20)

 

关注者编号

Funs_id

Varchar(20)

 

表名

被关注者表

字段名

字段代码

字段类型

描述

编号

Id

Number

主键

用户名

User_id

Varchar(20)

 

被关注者编号

Wasfuns_id

Varchar(20)

 

我看到这样的设计我很吃惊,试想一下,假如我一个用户对应有1W个关注者,那么该用户就会在关注者表中存在一万条他的记录,这难道不是严重的数据冗余吗?这甚至不符合数据库的设计规范。但是事实上证明,这种设计对大数据量的扩展是很不错的,既然如此,那假如用户和用户之间的关系不只是限于关注和被关注的关系,是不是又要新增表

解决方案三:

         话说“合久必分,分久必合”,对上述的设计再进一步修改,于是将方案二的两张表又合二为一,如下:

表名

关注和被关注者表

字段名

字段代码

字段类型

描述

编号

Id

Int

主键

用户名

User_id

Varchar(20)

 

目标对象

Operate_object

Varchar(20)

 

状态

Status

Number

当目标对象为关注者,标示为1;

当目标对象为被关注者,标示为2;

当双方互相关注,标示为3;

当目标对象为OO,标示为XX。

OK,这样的设计不仅解决了相当一部分的数据冗余,而且还能表示用户之间的多种关系,方便系统日后的扩展。但是问题又出来了,很明显这样设计对状态的维护也是存在疑问的,用一张表代替多张表,数据肯定是成倍的增长,是否不符合当前常说的“拆库拆表”的战略方针(好像这样的状态一般用于“标记男女”或者“是否删除了”之类的,貌似用于这种场合比较的少)。

在上述用户关系的解决方案中,可以很简单的归结为就是一对多,多对一,多对多的关系嘛,那么究竟如何设计,究竟哪种更好,希望大家共同分析!

冰 河 CSDN认证博客专家 分布式与微服务 大数据与云计算 云原生
微信搜一搜【冰河技术】 ,关注后回复【PDF】领取冰河原创超硬核PDF电子书,海量面试资料和简历模板。冰河,《海量数据处理与大数据技术实战》,《MySQL技术大全:开发、优化与运维实战》作者,【冰河技术】公号作者,基于最终消息可靠性的开源分布式事务框架mykit-transaction-message作者。多年来致力于分布式系统架构、微服务、分布式数据库、分布式事务与大数据技术的研究。在高并发、高可用、高可扩展性、高可维护性和大数据等领域拥有丰富的架构经验。对Hadoop,Storm,Spark,Flink等大数据框架源码进行过深度分析,并具有丰富的实战经验。
已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: Age of Ai 设计师:meimeiellie 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值