好友功能 的 数据库应该如何设计？
如题， 好友功能的数据库应该如何设计。。
例如：
用户表:
Table: UserInfo
Column: id --主键列，
name --用户姓名
好友表： 建立UserInfo 与 UserInfo 的一对多关系
Table: Friend
Column: userid --用户id1, 外键 与 UserInfo 中id关联
friendid --用户id2 外键 与 UserInfo 中id关联
疑问:
1. Friend表中是否要将userid和friendid同时表示为主键....
如果同时设置为主键则在Hibernate中如何创建改关系的实体类？（我在用MyEclipse5.5生成Friend表的实体类时总是反射出两个实体类）
2. 如果使用如下对象关系来描述 好友关系。那么数据库应该如何设计：
public class UserInfo {
private int id = 0;
private String name = null;
private Set<userinfo> friend = null;
}
如上面代码描述的关系， 如果一个用户有1w个好友，那么是不是在使用Hibernate中的Session.get()方法来获取改对象时，是不是会把1w个好友数据也存放到了Set中。 如果是这样那么怎样才能解决效率问题. (刚刚接触Hibernate，对这方面有很多问题还不是很清楚)
[quote] 1. Friend表中是否要将userid和friendid同时表示为主键....
如果同时设置为主键则在Hibernate中如何创建改关系的实体类？（我在用MyEclipse5.5生成Friend表的实体类时总是反射出两个实体类）
[/quote]
其实要进行这样的设计，Friend表中采用复合主键是没有必要的，你要维护的表之间的关系比较简单，userid作为外键完全可以维护一对多的关系，所以用复合主键反而增加了难度，如果你硬要这样，hibernate也提供了很好的支持：实现请参考
http://www.blogjava.net/alex/archive/2006/11/09/80231.html
兄弟， 什么工具允许你用1W个好友的？ 我觉得有1024个就差不多了。设置一个上限。
另外， 如果这么庞大的的系统， 你觉得会用hibernate来做么。 我不想说hibernate使用的是非。
好友系统的设计最难不是一个人有几个好友的问题， 这个可以通过CACHE来实现的。 最关键的是， 如果有1000W个用户， 每个人都有500个好友， 这5B的数据如何管理的问题。 比如QQ这样的系统。 如何分布式管理这些数据是最大的难题。 如果你能解决这个问题， 那么你离互联网技术大师的距离也不远了：）， 当然是夸张了点。 但是确实如此.
1.不用使用复合主键
2.使用二级缓存就不存在效率问题，将UserInfo缓存起来。