县需要设计一个共享数据库,
具体表结构为:
用户表、消息表。用户表、消息表...等A 用户发布了一条信息AA。
AA 默认情况下只能被A看到。
但是A可以将AA共享给用户B或者C、D、E、F(用户)信息具有分享的功能。
要求信息量大的情况下不会造成数据库拥堵。 在信息便利查询时能畅通!

解决方案 »

  1.   

    用户表 (userid, userName, .....)
    A,
    B,
    C,
    D,
    E,
    F消息表 (msgID, userid, title, content, ..)
    AA, A, 'hello World','content of the hello world'消息分享表 (msgID,userid,..)
    AA, B
    AA, C
    AA, D
    AA, E
    AA, F
      

  2.   

    huihong1024 (huihong1024)
      '截至2012-02-02 17:09:05  用户结帖率0.00% 当您的问题得到解答后请及时结贴.
    http://topic.csdn.net/u/20090501/15/7548d251-aec2-4975-a9bf-ca09a5551ba5.html
    http://topic.csdn.net/u/20100428/09/BC9E0908-F250-42A6-8765-B50A82FE186A.html
    http://topic.csdn.net/u/20100626/09/f35a4763-4b59-49c3-8061-d48fdbc29561.html8、如何给分和结贴?
    http://community.csdn.net/Help/HelpCenter.htm#结帖
      

  3.   

    那如果我要知道A 用户有多少条自己的信息如何组建查询语句?
    查询结果要能是
    消息表.Id 消息表.content  用户表.userName
      

  4.   

    做个三表的连接查询不就行了? 
    select * from 用户表,消息表,消息分享表 where a.userid=b.userid and b.msgID=c.msgID where b.userid='A'
      

  5.   

    不是每次查询都必须去查询数据库,你可以把查询结果缓存10秒钟,新浪微博的消息提醒就是用redis来缓存新消息的。
      

  6.   

    不是没错都必须查询数据库?结果缓存10秒具体如何实现?能给个URL我具体了解一下吗?
      

  7.   

    如果按照您的设计,
    有10个用户每个用户发布了10条信息,
    那么消息分享表,就会有100条记录。如果这10个用户在相互分享,
    消息分享表将有1000条记录。如果是100个用户100条信息 则有10000条记录,若是相互分享则有
    1000000条记录
    相当于A×A×A三次方来递增。要是再匹配上3表连查那效率可想而知。
    不知道有没有更好的设计思路或者分表来解决我这一数据库连查缓慢的问题?