kalman03

每天早上看一遍《福布斯》富翁排行榜,如果上面没有我的名字,我就去学习......
随笔 - 22, 文章 - 0, 评论 - 86, 引用 - 0
数据加载中……

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

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

解决方案一:

表名

用户信息表

字段名

字段代码

字段类型

描述

用户名

User_id

Varchar(20)

主键

登陆密码

Password

Varchar(20)

……

……

……

表名

关注和被关注者表

字段名

字段代码

字段类型

描述

用户名

User_id

Varchar(20)

主键

关注者

Funs

Text

 

被关注者

Wasfuns

Text

    这是我最初想到的一种设计,这里“关注者”和“被关注者”都是采用拼接一些特殊字符分割存储的,比如A用户有只有关注者BCDE,那么存入数据库关注者字段的数据将是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,这样的设计不仅解决了相当一部分的数据冗余,而且还能表示用户之间的多种关系,方便系统日后的扩展。但是问题又出来了,很明显这样设计对状态的维护也是存在疑问的,用一张表代替多张表,数据肯定是成倍的增长,是否不符合当前常说的“拆库拆表”的战略方针(好像这样的状态一般用于“标记男女”或者“是否删除了”之类的,貌似用于这种场合比较的少)。

在上述用户关系的解决方案中,可以很简单的归结为就是一对多,多对一,多对多的关系嘛,那么究竟如何设计,究竟哪种更好,我很难理解,期待大家拍砖!

posted on 2010-07-19 19:23 kalman03 阅读(8215) 评论(13)  编辑  收藏 所属分类: 数据库

评论

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

我认为方案二是最清晰的
2010-07-20 09:31 | cxh8318

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

方案3, 以后可以根据状态做分区或者路由.
2010-07-20 09:48 | dead_lee

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

为什么不是这样呢
create user (
user_id varchar(20) primary key,
password varchar(160)
);
create watches (
id int primary key,
watcher varchar(20),
watchee varcher(20)
);
2010-07-20 09:54 | anon

# re: 一个微博数据库设计带来的简单思考[未登录]  回复  更多评论   

用户表,用户-崇拜对象表,用户-粉丝视图

需要关注的是后两者的数据量
2010-07-20 10:16 | Wade

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

我认为这三个方案的优劣顺序为 2>1>3, 3会让处理逻辑变得非常复杂,其实方案2应该只要一个表就可以了,fans表,因为关注和被关注是互逆的,查不同列就可以了,这样的关系表最能体现数据库管理数据的长处。
2010-07-20 15:21 | HiMagic!

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

很想知道sina围脖的库是怎么设计的,有知道的分享一下。
2010-07-21 10:57 | Robin's Java World

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

@Robin's Java World
我也很想知道
2010-07-22 11:44 | kalman03

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

赞同@anon
2010-07-26 16:15 | watcher

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

不知道为什么这么多人说方案2好
2011-04-08 13:15 | dohkoos

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

写错了,没看清。
如同HiMagic!和anon讲的,其实方案2只要一张表就可以了
create users (
user_id varchar(20) primary key,
password varchar(160)
);
create watches (
id int primary key,
watcher varchar(20),
watchee varcher(20)
);

方案3是根本看不懂,不知道Operate_object这个是什么东西
2011-04-08 13:19 | dohkoos

# re: 一个微博数据库设计带来的简单思考[未登录]  回复  更多评论   

可不可以这样呢,让数据适当的冗余下,

user
{
user_id,
user_pwd,
……
fansid,
followersid
}

relationship --这个是互逆的
{
id,
uid,
fanid
}
2011-06-28 17:32 | shine

# re: 一个微博数据库设计带来的简单思考[未登录]  回复  更多评论   

方案2较好

一个用户,不会去关注数以万计的人。。。实践证明,有几千,已经很很大了。

但一个用户,可能被数千万人关注,这个是重点要解决的数据膨胀。这个容易实现水平分割。
2012-03-01 10:25 | allen

# re: 一个微博数据库设计带来的简单思考  回复  更多评论   

@anon
比较赞成这种方式!第一种数据冗余,在数据量大时,关系变更时操作复杂。第三种方案同样的逻辑,关系变更时操作复杂!
2016-02-17 13:50 | ManKane

只有注册用户登录后才能发表评论。


网站导航: