请大家进来一起讨论下网页中“相关资源”和“喜欢这个也喜欢”的设计

谢谢，关于“相关资源”的问题，我知道该怎么做了，需要对内容进行聚类，相关的算法有待研究，就不再这里讨论了。

“喜欢这个的人也喜欢”的问题，我还是没有一个好的解决方案。希望高手出来提提建议。

其实涉及的只有2张表

例如：

用户表： book {bookid,userid}

数据：
1, 'aaa'
2, 'bbb'
3, 'ccc'
4, 'ddd'
5, 'eee'
6, 'fff'
7, 'ggg'
8, 'hhh'

关系表：userbook {userid,bookid}

数据：
1, 1, 1
2, 1, 2
3, 1, 3
4, 2, 2
5, 2, 3
6, 3, 6
7, 3, 8
8, 4, 3
9, 4, 5
10, 4, 6
11, 4, 7

例如喜欢bookid=3的人还喜欢：

select distinct b.bookid,b.name from userbook ub,userbook ub2,book b where ub.bookid=3 and ub2.bookid!=3 and b.bookid=ub2.bookid and ub.userid=ub2.userid;

userbook：对于 bookid建立索引 userid建立索引

这个问题的本质是E[xi*xj]/sqrt(E[xi*xi]*E[xj*xj])，概率空间的元素是用户（或session），随即变量xi是用户有否点击资源i（0，1），E是期望。

建一个表，三个子段，资源a，资源b和他们的相关系数。

起一个后台进程，遍历用户（或session），计算E[xi*xj],E[xi*xi],E[xj,xj]，再持久化就可以了。

这里要注意的是资源的数量可能很大，但是每个人点击的资源很少，不然就没得玩了。后台进程的复杂度为O[n*n*l]，n为平均每个人点击的资源，l为用户数，所以这个进程计算量不会大得离谱的。

使用的时候select * from cov where res_a=a and cov>threshold

所有的挑战在与资源数过多怎么办，如果资源只有几k的话，jvm内存开大点，在内存里就可以搞了，持久化的时候滤掉很小得项，再不行就kl变换，不过还要反变换回来，很烦。

如果资源上万，观察E[xi*xi]的分布，差距大的两个资源协差都认为是0，如果分布很平均，那只能根据用户属性对用户作聚类了，对每个聚类单独建这样的协差模型

这个应该是：协同过滤推荐算法。

楼主可以去搜索一下。在数据量大的时候，要做到实时统计还是一件很困难的事情。

在看一下这个表的数据量大概多大，很显然，不会超过n*n*l，l为用户数,n为平均每个人点击的资源，不会很大，而且这是最糟的情况，任何两个人没有共同的两项爱好，实际的数字肯定小得多，因此，如果内存和db吃得消，就没必要做后面那些复杂的事情。

要好好学习一下概率了，一看到算法就头痛，现在没办法要硬着头皮去啃了

来个实惠的，每个资源录入的时候填写一个关键字，然后按关键字一查！搞定！哈哈哈哈哈！！！