单表内用户关联实现问题：是否需存储双向关系及其他实现方案

是否需要存储双向重复的用户关联关系 #

是否需要存储双向记录完全取决于你的关联关系类型：

• 如果是无向对称关系（比如好友、亲属这类双方身份对等的关系，A是B的好友等价于B是A的好友）：完全不需要存储双向重复记录，冗余存储反而会带来数据一致性风险，比如删除1-2关系时漏删2-1，就会出现单边显示好友的错误。
  这种场景建议新增约束要求id_user_1 < id_user_2，插入数据时自动把更小的用户ID放在前字段，从根源避免重复关系插入。查询用户的所有关联时用OR条件匹配两个字段即可，示例SQL：

  SELECT CASE WHEN id_user_1 = 待查用户ID THEN id_user_2 ELSE id_user_1 END AS relation_user_id
  FROM relation_ids
  WHERE id_user_1 = 待查用户ID OR id_user_2 = 待查用户ID
  

• 如果是有向非对称关系（比如关注、拉黑这类有主动被动区分的关系，A关注B不代表B关注A）：需要分别存储两条独立的双向记录，二者的关系状态互不影响。

从你给出的样例数据判断，你的需求应该是对称类关联，不需要存储双向重复记录。

同表实体关联的其他实现方式 #

• 带扩展字段的关联表：如果后续需要支持多类关联，可以在现有关联表基础上新增relation_type（区分好友、拉黑、同事等类型）、created_at（关系创建时间）、status（关系生效/失效状态）等字段，兼容更多业务场景。
• 邻接表字段：如果是一对多的层级类关联（比如用户邀请上下级、组织归属），可以直接在User表新增parent_user_id字段存储上级用户ID，不需要单独建关联表，维护成本更低。
• 闭包表：如果需要高频查询多层级关联（比如查询用户的好友的好友），可以新增闭包表存储所有节点的全路径关联，多级查询效率很高，但数据维护成本也会对应提升。
• 数组字段：如果使用支持数组类型的数据库（比如PostgreSQL），且单用户关联数量不多，可以直接在User表新增relation_user_ids数组字段存储关联用户ID，单用户关联查询速度更快，但反向查询、批量统计的难度较高。

内容的提问来源于stack exchange，提问作者Владимир Кузовкин