有趣的是我从来没有遇到过这个！
我从来没有想过一个人可以在一张桌子上建立“多对多”关系，直到我开始开发一种用户可以互相“加好友”的系统（社交网络）。
标准查找表，至少以我习惯使用的方式，在这里不合适。让我们保持简单：
用户表有“id”和“name”列。
User_relationship 表有“uid1”和“uid2”，代表用户是“朋友”或“好友”或“伙伴”或“其他”。
很快就可以看出这里的问题是什么 - uid1 和 uid2 是来自同一个表的同一列的相同数据类型，这意味着唯一键存在缺陷。
例如。：
uid1 = 1
uid2 = 2
是相同的：
uid1 = 2
uid2 = 1
因此，如果查询执行错误，可能会返回 2 条记录，或者返回 0 条记录。
本着精心设计表格的精神，我不想扫描整个表格两次来检查现有值。
有什么技巧可以处理这个问题吗？这是一个我从未想到过的设计问题，它让我烦恼，因为我知道有一些简单的技巧可以让它发挥作用。
在你问之前，我还没有尝试过任何东西，因为我已经看到我最喜欢的关联事物的方式（查找表）不足以满足我的需求，我需要一些帮助 - 我在SO或Google上找不到任何东西:(
提前致谢。
如果您描述的关系是对称的，例如“Bob 是 Joe 的朋友”意味着“Joe 也是 Bob 的朋友”，那么您可以在代码中确保 2 个用户 ID 中较小的一个出现在第一列，较大的放在第二列。此约束几乎可以确保查找表中的记录是唯一的。这也意味着当您执行查找时，通常必须搜索两列。
例如，如果您尝试获取 Bob 的所有朋友，则必须查询任一列中包含 Bob ID 的记录。这会导致代码增多，并可能影响性能。
如果关系可以是不对称的，如“Bob 是 Joe 的朋友”并不一定意味着“Joe 也是 Bob 的朋友”，那么每对用户需要 2 个条目：Bob - Joe 和 Joe - Bob。这意味着您的查找表将包含两倍的条目，并且您的网站对跟踪者非常友好：D 当然，即使您的关系是对称的，您仍然可以选择应用此系统。
使用此方法，如果您想获取 Bob 的所有朋友，您只需在第一列中选择具有 Bob ID 的记录即可。这可能意味着更快的查找和更少的代码需要编写，但同样，这意味着您在数据库中占用更多空间。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
