在GraphQL中，用属性还是关联区分对象关系更优？

场景与问题 #

用户既可以拥有书籍，也可以参与书籍贡献。当前查询用户拥有书籍的GraphQL语句如下：

viewer {
  id
  books {
    id
    title
  }
}

其中viewer属于GraphQL的User类型，books返回Book类型数组。

现在需要查询用户参与贡献的书籍，但这类书籍同样属于Book类型，该如何区分用户拥有和贡献的书籍？目前有两种候选方案：

方案a：属性标记方案 #

• 对客户端更友好，只需通过books字段即可获取用户可访问的所有书籍，通过新增字段标记身份

viewer {
  id
  books {
    id
    title
    userIsContributor
  }
}

方案b：独立关联方案 #

• 对服务端更友好，贴合数据库 schema：用户通过user_id关联拥有的书籍，通过contributors关联表关联贡献的书籍

viewer {
  id
  books {
    id
    title
  }
  contributedToBooks {
    id
    title
  }
}

方案分析与补充要点 #

GraphQL社区没有绝对的“标准实现”，选择哪种方案核心取决于业务需求和团队的权衡：

1. 方案a的适用场景

   • 客户端需要频繁同时展示用户拥有和贡献的书籍，且需要统一处理这两类数据
   • 业务上允许用户同时拥有并贡献同一本书（此时userIsContributor和“拥有”状态可共存）
   • 注意：如果用户可访问的书籍数量极大，一次性返回所有数据可能带来性能问题，需要配合分页、过滤参数优化

2. 方案b的适用场景

   • 服务端数据模型中“拥有”和“贡献”是完全独立的关联关系，分开查询更符合数据结构
   • 客户端经常需要单独获取某一类书籍（比如单独展示“我拥有的书”或“我贡献的书”）
   • 优势是查询更灵活，可单独请求某一类数据，避免不必要的字段传输

3. 未考虑的要点

   • 权限与数据范围：两种方案都需要明确books和contributedToBooks返回的数据范围，比如用户是否能看到自己未拥有/未贡献的书籍？是否需要过滤私有书籍？
   • 字段复用：如果Book类型有大量字段，两种方案都可以通过片段（Fragment）复用查询逻辑，避免重复编写字段
   • 性能优化：方案a如果返回大量数据，要考虑添加过滤参数（比如filter: { isContributed: true }）来按需获取；方案b要注意避免N+1查询问题，服务端需要做好数据预加载
   • 业务扩展性：如果未来要增加更多用户与书籍的关系（比如“收藏的书”“浏览过的书”），方案b的模式更容易扩展，只需新增字段；方案a则需要不断添加新的标记字段，可能导致Book类型字段膨胀

内容的提问来源于stack exchange，提问作者Perennialista