微博的关注系统.

我想问问各位高手哟.微博系统是怎么保存好友的呢?是以ID1,ID2,ID3然后转换数组读取.还是每个用户另外开一个表来另外保存呢?如果是另外开表.那不是会很麻烦?管理其他也会很不方便?这种好友系统的数据库应该是怎么样设计的呢?跪求各位高手指点..

解决方案 »

  1.   

    如果 是每个用户另外开一个表来保存 的话，一万的用户就有一万个表，十万个用户就有十万个表。显然是不现实的如果 以ID1,ID2,ID3然后转换数组 的话，实现上是可以的，不过要用text类型字段。否则可能出现容量不够
    如果用的是 mysql 数据库，则建议采用这种方式，利用mysql提供的 find_in_set 函数，不用转换成数组就可查询
      

  2.   

    一般都是另开一个表，这个表专门用来干好友这个功能的，有pid(父id---某个用户的id)，还有好友id（其实也是其他用户的id），当然了pid对应的好友中存放好友id的模式一般是：1, 2, 3, 4说明了某个pid的好友有id为1， 2， 3， 4这个几个用户，如下：
    表（table_friends）
    pid     friends
     1      1,2,3,4
     2      23,34,2说明了
    某个用户（id是1的）的好友有id为1、2、3、4的用户
    某个用户（id是2的）的好友有id为23、34、2的用户不知道楼主看明白了么
      

  3.   

    一个用户一个表，查询和维护起来太麻烦了。在用户表的好友字段中以ID1,ID2,ID3这样的形势存储比较好。
      

  4.   

    估计楼主说的不是一个用户一个表，而是单独将ID1,ID2,ID3的功能分离出一个表来
      

  5.   

    以id1,id2,id3这样的保存方式,我觉得并不是很好,当查找某个用户其中一个好友的时候,并不是很方便,我做的方式是,一个会员添加一个朋友就一条记录,当然这是建立在前期记录不是很多的时候,如果真是记录数很大,到考虑把这个表相应的分表就可以了.
      

  6.   

    但是每个记录也许同时是N个人的好友呢？那么还是要id1,id2,id3，反正php有内置函数explode操作很方便
      

  7.   

    可以考虑serizlize进行串行化（就是不知道楼主怕不怕麻烦）
      

  8.   

    很简单啊，建一张friend的表 列明为 朋友ID 主人ID 就可以了 主人就代表你的ID 朋友就代表你的朋友ID
      

  9.   

    关系表，有什么问题么。没有一个字段也没啥问题，就是麻烦点。也许别人用的不是mysql数据库，用的是oracle呢。几千万的数据是个小意思。还能有什么问题呢？
      

  10.   


    这种形式不好。使用不方便。
    id  fid
    1    2
    这样就好了。
      

  11.   

    表格形式
    userid    friendid
      1          2
      1          3
      1          4
      

  12.   


    添加一个字段就可以了
    userid    friendid   friendtype
      

  13.   


    没关系啊 比如说找你的朋友 select * from friend where 主人ID = ‘你的ID’ 这样就找到你所有的朋友，如果要有分类的话 你在这表上在加个字段就可以了，如果你想分类再可以无限添加或自定义各种操作的话，你也只需在做个朋友分类的表，道理跟朋友的表是一样的有个主任的ID表明所属就可以了
      

  14.   

    那就把分类也记上
    userid friendid typeid
    1      2        1
    2      3        3
    1      4        9
    3      4        10
    3      1        5
      

  15.   

    看了这以上这么多能不能这样?二张表或三张表; 第一是记录表,即加好友表(也可以再细分二个表)按 uid,fuid,type,status之类的第二个是用户好友表
      即uid, friends这个表可以存字串,或序例化对,主要方便查询每当有用户好友操作时,更新用户好表.平时查询,除特别情况,只查用户好友表
      

  16.   

    有点不懂..你所说的这两个表和.开一个表.uid,fuid,type.status,friends有什么区别呢?
      

  17.   

    主要是看你查询是否方便以要求？如果是uid, friends 表，记录级别是单一的。即使百万级用户，则只是百万级用户记录如果每个好友一个记录。
    则记录是其平方数。可能的结果是比如1万用户，每人100个好友。则记录为100万或200万级。或果联表查询，临时表到一定级别，性能明显降低。但有时候你查询只能从用户-好友单记录中查询。表的设计：一是能满足你的查询；二是效率不降低。看你取舍。
      

  18.   

    我觉得关注就应该是有序图结构。
    每个人为一个结构 
    p(i,j) 代表 i 关注 j
    数据库里面就应该是直接离散的存 
    关注序列表  关注方 被关注方
    1 2,3,4
      

  19.   

    没听过有序图，只听过有向图。。
    高深，不懂。。大概就是a是b的好友，b是a的好友对应2条记录
    uid fuid
    a   b
    b   a