同桌上的多对多

Question

有趣的是,我从未遇到过这个!

我从来没有想到一个人可以在一张桌子上拥有"多对多"的关系 - 直到我开始研究用户可以互相"交朋友"的系统(社交网络).

标准查找表,至少在我习惯使用它的方式,在这里是不合适的.让我们保持简单:

用户表具有"id"和"name"列.

User_relationship表具有"uid1"和"uid2",表示"朋友"或"芽"或"好友"或"其他任何"的用户.

很明显这里的问题是什么 - uid1和uid2是来自同一个表的同一列的相同数据类型,这意味着唯一键变得有缺陷.

例如:uid1 = 1 uid2 = 2

是相同的:

uid1 = 2 uid2 = 1

因此,如果查询执行错误,则可以返回2条记录或0条记录.

本着设计好表的精神,我不想两次扫描整个表以检查现有值.

处理这个有什么技巧吗？这是一个从未发生过的设计问题,它让我感到烦恼,因为我知道有一些简单的技巧可以让它发挥作用.

在你问之前,我还没有尝试过任何东西,因为我已经看到我最喜欢的关联方式(查找表)不足以满足我的需求,我需要一些帮助 - 我在SO或Google上找不到任何东西:(

提前致谢.

Answer 1

意味着唯一键变得有缺陷.

uid1 = 1 uid2 = 2

是相同的:

uid1 = 2 uid2 = 1

不,不是.

例如,在Facebook上,我有一些客户发出请求成为我从未接受的"朋友"......因为他们只是熟人.

同样,我可能会将一些人标记为最好的朋友,他们没有回应,反之亦然.或许我忽略了一些而他们不是.

基本上,(uid1, uid2)元组中的信息比仅仅ID更多.

在决定uid1 < uid2在桌面上添加约束之前,请确保您永远不需要处理这些情况.

Answer 2

如果您描述的关系是对称的,如"Bob是Joe的朋友"意味着"Joe也是Bob的朋友",那么您可以在代码中确保2个用户ID中的较小者继续第一列,较大的一列在第二列.这种约束几乎可以确保查找表中的记录是唯一的.这也意味着当您执行查找时,通常必须搜索两列.

例如,如果您试图获取Bob的所有朋友,则必须在任一列中查询具有Bob ID的记录.这会导致更多代码,并可能对性能产生影响.

如果关系可以是不对称的,如"Bob是Joe的朋友"并不一定意味着"Joe也是Bob的朋友",那么每对用户需要2个条目:Bob - Joe和Joe - Bob.这意味着您的查找表将包含两倍的条目,并且您的站点对跟踪器非常友好:D当然,即使您的关系是对称的,您仍然可以选择应用此系统.

使用此方法,如果您想获得Bob的所有朋友,您只需在第一列中选​​择具有Bob ID的记录.这可能意味着更快的查找速度和更少的代码供您编写,但同样,这意味着您在数据库中占用更多空间.