如何设计一个用户“喜欢”另一个？

Question

我认为这有点像朋友，但并不需要双向。像这样：

from_user   to_user
-------------------
John        Mary
Mary        John
John        Susan
Mary        Dave

如果有任何问题，我很好奇，如下所示。

user1       user2      mutuality 
--------------------------------
John        Mary       2
John        Susan      1
Mary        Dave       1

第二个似乎会有更复杂的查询和检查，但最终是否会节省空间？例如，如果Susan最后一天为John而堕落，那么您将检查user2是否为Susan而user1是否为John。如果存在，则将相互性更新为2.如果不存在，则插入新行[Susan，John，1]。那样的东西？

最好的方法是什么？

Answer 1

我会选择第一种方法。使用第二种方法时，您最终不会节省足够的空间。由于每个选项（例如）都是一个操作，因此拥有一个单独的记录来存储该操作与工作流程相匹配。约翰喜欢玛丽，添加一条记录。玛丽喜欢约翰，添加另一条记录。玛丽不再喜欢约翰，删除那条单曲。这对我来说更容易维护。我发现把东西放在较小的颗粒状部件中可以保持简单。

在设计方面，我建议您不要在likes表中使用字符串名称，而应该有一个users表，每个用户都有一个主键ID（唯一）。这样，用户可以在不破坏关系的情况下修改名称。

表数据如下所示：

Users table
id Name
1 John
2 Mary
3 Susan
4 Dave

Likes table
From To
1    2
2    1
1    3
2    4

表格具有以下结构

users
-----
id (integer autoincrement)
name (varchar)

likes
-----
id (integer autoincrement)
fromid (integer)
toid (integer)

sql看起来像这样产生列表

SELECT f.name as fromName, t.name as toName
FROM (likes JOIN users AS f ON likes.fromid = f.id) 
JOIN users AS t ON likes.toid = t.id;

Answer 2

第二种方法允许以下异常：

user1       user2      mutuality 
--------------------------------
John        Mary       2
Mary        John       1

John和Mary是否相互喜欢（如第一行所暗示的那样），或者只是Mary单向喜欢John（如第二行所暗示的那样）？

第一种方法并不存在这种不一致性，数据完整性通常比节省一些空间更重要。

---

顺便说一句，如果你引入一个整数surrogate key并从联结表中引用它（而不是实际名称），联结表将变得更加精简，从而否定了第二种方法的大部分空间优势。 / p>