这是一个社交网站。让Facebook成为我们的典范。
在mysql服务器中有一个表：'posts'以保留所有帖子的约束（为简单起见，不包括注释）。它的列是：
id，post，user_id，frnd_id_1，frnd_id_2。
id：主键，自动递增。
帖子：写在墙上的帖子（无论是登录用户的墙壁还是他/她的朋友之一）
user_id：登录用户的ID（假设为A）
friend_id_1：已登录用户的朋友（假设为B）。当A写在B的墙上时，会使用此字段。
friend_id_2：登录用户的朋友的朋友（假设为C）
如果在A和B之间有任何消息对应关系，则相应地记录在mysql表中。
假设B在C的墙上写了一些东西，然后B的朋友会在他们的个人墙上看到它。假设B有100个朋友。我们可以这样的方式在上表中记录它：frnd_id_2将用于保存C的id的记录;
如果frind_2的记录为'0'，则消息对应关系仅在user_id和frnd_id_1之间，否则表示frnd_id_1已写在frnd_id_2的墙上，而frind_id_1是user_id的朋友。
到此为止，我认为，一切都与FACEBOOK完全相似。
但是 -
假设B有100个朋友。在这种情况下，如果B写在C的墙上（假设所有隐私设置都为朋友的朋友打开）。如果采取上述政策，表格中将有101条记录：
1）一条记录意味着B已经贴在C的墙上（frnd_id_2 = 0）。（我们称之为主记录）
2）B的100位朋友的另外100条记录（frnd_id_2！= 0）
这就是我脑中的方式。我可以通过插入'post'列（或保持'post'列空白并创建另一个，即'main_record_id'）而不是完整的消息，而是主记录的id来改进它。
但问题是：对于单个帖子，需要执行101个db查询（在这种情况下）。还有其他任何提高数据库性能的方法吗？
我使用PHP作为脚本语言。
答案 0 :(得分：0)
或者1个数据库查询，它在一次网络往返中返回所有信息。我将它们批处理成一个JOIN查询。
如果您打算保留所有这些记录，则无法存档，但您可以控制如何访问它们。
要记住的另一个想法是控制返回的结果集的大小。你真的需要所有100个朋友吗？你能一次做十个吗？当您有1,000或10,000条记录要返回时，这将变得尤为重要。
答案 1 :(得分：0)
一个简短的回答：不要将MYSQL用于类似facebook的墙 - 它对于此类目的来说非常无效。
使用no-sql数据库代替MongoDB。我保证，对于使用不同类型的对象的实时新闻源，它会更加方便。
你也可以组合两个数据库：MongoDB for newsfeed和MySQL for everything else。