微博数据库设计的思考

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

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

解决方案一：

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

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

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

评论

# 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这个是什么东西