微博(Micro-Blog)顾名思义是微型博客，是一种基于用户关系的信息分享和传播平台,用户可通过浏览器、手机、及时通讯软件(MSN、QQ、Skype 等)及外部 API 接口等多种渠道发布 140 字以内信息[1]。支持跨平台交流、与移动设备无缝连接的技术优势,饱含 Web2.0 特质。 有这么一道题 - 微博数据库设计：有 A,B,C3 个用户，A 关注 C，C 关注A 和B；A,B 更新后 C 会收到信息提示,比如： 2010-11-16 22：40 用户A 发表 a1; 2010-11-16 22：41 用户A 发表 a2; 2010-11-16 22：42 用户A 发表 a3 2010-11-16 23：40 用户B 发表 b1; 2010-11-16 22：40 用户B 发表 b2; 问题 1：如何设计数据表和查询？ 问题 2：如果 C 关注了 10000 个用户，A 被 10 万个人关注，系统又该如何设计？ 问题 1，我的解答是：设计两张表，一张用于表示用户user，有 ID,用户名(username)，发布内容（message），发布时间(time)等字段；另一张表用于表示用户之间关注，有 ID，用户名(username)，关注的用户名，开始关注时间等字段。回去想了想，发现如果数据表照我这样设计的话，问题 2 的情况就会产生大量的数据，但如果把关注的用户都写在一个记录里那样字符串可能会更大。所以想听听诸位达人的意见，如果是你们会怎样设计数据表呢？ 问题 1 简单而且随意，直接跳过，估计面试的人都不会看。问题 2 的困难在于： 第一点. C 关注的用户太多，设计上必须在显示 C 的页面的过程中，避免去数据库查询所有被关注的用户是否有更新。 第二点. 第二点.A 被关注的人太多，设计上必须在 A 更新的时候，避免去通知所有关注…… 为避免不必要的复杂连接关系，最好还是设计符合第三范 式的关系数据。 我想至少应该设计三张表，分别是： 用户表 user：ID，username...； 关注关系表 attention: ID->ID； 发布信息表 in fo：ID->message； 三张表的设计是比较规范的，至于用户和关注之间的关联要看需求，做 join 也可以，做 DataMap 也可以。 个人觉得，需要的逻辑关系在哪儿，而且要进数据库，想不数据量大都不行。当然关注可以不做在一张表中也是一个选择，按关系类型分开走，可以减少特定需求的查询量。 这玩意得丢内存里头吧 memcached 发新的话题的话丢队列里头写数据库去 user { befollow[0...n]; post[0...n]; topics[0..n]; } 然后，user[befollow[k]].topics=current_user.topics[...
