我需要一些设计朋友系统的帮助
mysql表：
friends_ list
- auto_ id
- friend_ id
- user_ id
- approved_ status
选项1 =每次用户添加用户时，都有2个条目添加到数据库中，然后我们就可以找到这样的朋友
SELECT user_id FROM `friends_list` WHERE friend_id='$userId' and approved_status='yes'
选项2 =我们为每个添加的朋友添加1个条目，然后像这样获取朋友列表
SELECT friend_id AS FriendId FROM `friends_list` WHERE user_id='$userId' and approved_status='yes'
UNION
SELECT user_id as FriendId FROM `friends_list` WHERE friend_id='$userId' and approved_status='yes'
在上面的2个方法中，有朋友在像myspace，facebook这样的网站上，所有其他网站都有，上面两种方法中的哪一种最佳表现？
第一种方法将行数增加一倍，例如，一个拥有200万朋友行的网站只有100万行第二种方法。
然而，union方法意味着有2个查询，所以2个查询在一百万行表而不是1？
更新
我刚刚对60,000个朋友进行了一些测试，结果就是这样，是的，表格已被编入索引。
选项1，每位朋友有2个条目;
.0007秒
选项2，每位朋友使用1个条目，使用UNION选择
.3100秒
答案 0 :(得分：1)
选项1。
在添加朋友时尽可能多地工作。与选择所有朋友相比，添加某人是非常罕见的。每次渲染页面时都可能会做一些事情（在社交网站上）。
答案 1 :(得分：0)
如果要对user_id和friend_id建立索引，那么这两个语句应该在时间上是等效的 - 最好测试一下 - 数据库可以有惊人的结果。数据库可以看到UNION，它可以使用它来优化查询。
友谊是否始终相互并具有相同的审批地位？如果是这样，我会选择第二个。如果它可以单向或单独批准，那么你需要第一个，对吗？
答案 2 :(得分：0)
您使用的是哪个dbms？ MySQL在执行联合查询时总是使用额外的临时表。创建这些临时表会给查询带来一些开销，这可能是您的union查询比第一个查询慢的原因。
你有没有想过分开朋友和朋友的请求？这将减少好友表的内容，您还可以从好友请求表中删除已接受的请求，并保持表的大小。另一个好处是你可以在每个表中保留较少的列，从而更容易获得精确的索引。
我目前正在自己构建此功能，听听您对此事的体验会很有趣。
答案 3 :(得分：-1)
这类问题的答案倾向于依赖于使用模式。在你最常见的情况下：增加新的友谊关系或查询友谊关系？
此外，您还需要考虑未来的可能性，这可能是数据的用途。
我的猜测是，该选项是一个更清晰的数据模型，用于表示您要表示的内容。看起来它允许在不对称关系和朋友的朋友等方向上扩展。我认为这个选项将来会证明是不合适的。