一个微博数据库设计带来的简单思考
在微博系统中，当前用户、关注者（也就是粉丝）、被关注者（崇拜对象）这三种角色是少不了的。他们之间看似简单的关系，但是其中数据库表将如何设计，却让我很难琢磨，在如下解决方案中，你们会选择哪种?为什么要选择这种?是否有更好的解决方案?
解决方案一：
字段名
字段代码
字段类型
描述
用户名
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 达 人解答 不能通过？