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

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

解决方案一：

字段名

字段代码

字段类型

描述

用户名

User_id

登陆密码

Password

……

……

字段名

字段代码

字段类型

描述

用户名

User_id

关注者

Funs

?

被关注者

Wasfuns

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

字段名

字段代码

字段类型

描述

编号

Id

用户名

User_id

关注者编号

Funs_id

?

字段名

字段代码

字段类型

描述

编号

Id

用户名

User_id

被关注者编号

Wasfuns_id

?

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

解决方案三：

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

字段名

字段代码

字段类型

描述

编号

Id

用户名

User_id

目标对象

Operate_object

?

状态

Status

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

1 楼 guoyu04 2011-02-17 理解的很不错了，希望有da人解答。 2 楼 guoyu04 2011-02-17 达 人解答 不能通过？