当存储用户的关系数据（每个用户可能有一千个朋友）时，为每个关系创建一个新行或者将他们所有的朋友连接成一个字符串然后再解析它会更快吗？ / p>
即。
Primary id | Friend1ID | Friend2ID|
1| 234| 5789|
2| 5789| 234|
其中ID是对“用户”表中主要ID的引用。
或者'用户'表中只有一个名为friends的列，如下所示：
Primary id | Friend1ID |
234| 5789.123.8474|
5789| 234|
我理解字符串连接和解析通常很慢，所以我很想倾向于第一种方法。然而，随着用户数量的增长，这就变成了选择一行并解析它的情况.V搜索数百万行以查找符合WHERE标准的行。
一种方法明显快于另一种吗？特别是随着用户数量的增长。
答案 0 :(得分：3)
您应该使用第二个表来存储朋友。
Users Table
----------
userid | username
1 | Bob
2 | Mike
3 | John
Users Friends Table
--------------------
userid | friend_id
1 | 2
3 | 2
在这里你可以看到迈克是鲍勃和约翰的朋友......这当然是一个非常简单的演示。
你的第二个选项不会扩展，有些人可能会有成千上万的朋友，将每个Id存储在一个字段中会让人头疼。添加朋友，删除朋友。制定人与人之间的复杂关系。很多头顶。
在正确索引的表上使用WHERE子句查询数百万条记录的时间不应超过一秒，第一个选项是更好的选项。
答案 1 :(得分：2)
＆＃34;正确＆＃34;方式可能会保持多行。这允许更容易的统计分析和更复杂的查询（如朋友的朋友），没有任何hacky东西。整数存储大小通常也小于字符串存储，即使您重复一个ID - 特别是如果您使用适当大小的整数存储（如mediumint）。
它更易于维护，可扩展（如果他们开始得到很多朋友）出口和可导入。连接的速度增益（如果有的话）不值得其他好处。
如果你想要搜索Bob是否是Jane的朋友，那么这将是多行实现中的单行查找，或者是单行实现：获取Bob的行，解码字段，循环通过现场寻找简 - 找到简。在这种情况下，DBMS优化和索引会使多行实现更快 - 如果您将主键作为（id，friendid），那么它几乎是瞬时的，因为该表可能会在该键上进行哈希处理。 / p>
答案 2 :(得分：1)
我认为做到这一点可能更快的正确方法是两个做两列表
user | friend
1 | 2
1 | 3
它很简单，可以让您更轻松地进行排队和更新，并且您可以拥有任意数量的关系。
不要过分复杂化问题...
答案 3 :(得分：-1)
......要求更“正确”的方式本身就是错误的。 这取决于案例。
如果您对Web应用程序的访问率较低，那么更多的行不会改变硬币另一面的任何内容（我不是英文），在大中型应用程序访问中，最好是拥有最小的访问权限可能的数据库。
为了获得这个，你已经想过你可以连接这些值，然后在用户登录时拆分它们，然后将所有内容放入$_SESSION supervar。
至少这是我的想法。