shanshan888
shanshan888
2009-03-22 21:06
浏览 124
已采纳

如何高效: 数据库棘手问题

碰到一个问题:

如果想把看过某一篇新闻的所有的读者, 这些所以读者还看过的其他一些新闻全部或者部分罗列出来,

这种关系用数据库怎么高效表示出来呢

[b]问题补充:[/b]
[i]加一个多对多的中间表..

uid aid
1 1
1 2
1 3
4 1

这样,读者id,读过的新闻id..这样在每次一个读者读一篇新闻的时候要添加纪录到这个多对多表.这样要实现你所说的功能就很简单了.

一个读者所有读过的新闻

where uid=1

一个新闻所有的读者

where aid=2[/i]

这样感觉可行,可是还想把 链接的新闻 比如 30% 看过这篇新闻的人也看过另外一篇新闻,和 1% 看过这篇新闻的人也看过另外一篇新闻 区别开来,也就是想分析出其中的权重, 这上面这种解决方案感觉也行,可是感觉效率会很低, 有其他更好的方法么?

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

4条回答 默认 最新

  • playfish05
    playfish05 2009-03-22 21:57
    已采纳

    对于你的需求,这种方案其实最精确,因为它纪录到了id对id的程度,你的统计都是精确的.而且这种查询的效率不会低,因为它都是id主键的查询,这种查询的效率最高.

    而且你既然是想作为一个推荐的机制出现的功能,那实时要求其实并不高,如果你的量确实非常大,你可以将一次查询缓存起来,你每隔个3,5小时再重新查询一次生成新的推荐文章出来.

    或者你从另一个角度出发,你想知道的是看这篇文章的从哪里来,然后到哪里去.设计一个这样的表

    curid nextid count
    2 3 0

    比如从文章2跳到文章3的,计数+1,文章本身阅读次数1000,2跳到3的200,就可以20%的看过这篇文章的看的下一篇文章的统计.这样效率是很高,但是这是不精确的,比如一个读者,读了3,然后退出了网站,进来又读了2,从这样的表设计,你并不知道他读了3又读了2,它不是从2-3这样的路径.所以说如果要求精确可以用第一种,不精确可以用第二种.

    个人推荐还是第一种.只要结合一下查询缓存,3,5个小时查询生成一次不会对性能有太大影响.

    点赞 评论
  • zhoujuan520
    zhoujuan520 2009-03-22 21:08

    想提高查询速度,推荐建索引!这个是个好办法

    点赞 评论
  • playfish05
    playfish05 2009-03-22 21:10

    加一个多对多的中间表..

    uid aid
    1 1
    1 2
    1 3
    4 1

    这样,读者id,读过的新闻id..这样在每次一个读者读一篇新闻的时候要添加纪录到这个多对多表.这样要实现你所说的功能就很简单了.

    一个读者所有读过的新闻

    where uid=1

    一个新闻所有的读者

    where aid=2

    点赞 评论
  • zhoujuan520
    zhoujuan520 2009-03-22 21:46

    给playfish 分吧

    点赞 评论

相关推荐