AWS Amplify GraphQL场景下是否有必要额外创建独立User表？

是否需要额外创建独立User表 #

可以根据你的业务场景判断，两种方案的适用边界如下：

• 仅使用Amplify Auth自定义属性即可满足的场景：只需要存储和身份认证强相关的低频修改数据，比如用户昵称、头像地址、邮箱验证状态、注册渠道等。这种方案无需额外维护数据表，通过Amplify Auth的内置接口即可直接读写，权限天然和当前登录用户绑定。
• 必须保留独立User表的场景：
  • 需要存储的用户属性数量多、部分属性内容长度大，Amplify Auth底层依赖的Cognito默认最多支持50个自定义属性，单属性值最大2048字符，无法满足需求
  • 需要对用户数据做复杂条件查询、统计、聚合操作，Cognito不支持这类操作，独立User表配合索引可以实现
  • 需要和其他业务表做关联查询的场景

大型应用的通用用户信息处理逻辑 #

成熟项目一般会采用「身份层+业务层」的分层存储方案：

• 身份层：用Amplify Auth（Cognito）存储核心身份属性，比如登录凭证、邮箱/手机号、账号封禁状态这类和鉴权强相关的信息，仅在登录、鉴权环节读写
• 业务层：创建独立的User表存储所有业务相关的用户数据，表中保留cognitoSub字段和身份层返回的用户唯一ID做关联，所有业务逻辑的用户数据读写都走这张表
• 优势：认证逻辑和业务逻辑完全解耦，后续如果要更换认证服务、做跨端用户打通、做用户数据统计分析都不需要改动认证体系，权限控制也更灵活

未在GraphQL schema中定义User表能否建立关联关系 #

Amplify GraphQL的内置关联指令（@hasOne/@hasMany等）依赖schema中定义的模型生成，如果你没有定义User模型，无法直接使用内置指令建立关联。
如果不想维护完整的User表，又需要实现业务数据和用户的绑定，可以在对应的业务表中新增userId字段，存储Amplify Auth返回的用户唯一ID（即sub字段），手动做关联校验，也可以配合@auth指令实现权限控制，示例schema如下：

type Post @model @auth(rules: [{ allow: owner, ownerField: "userId" }]) {
  id: ID!
  content: String!
  userId: String! # 存储当前登录用户的sub值
}

这种方案不需要额外维护User表，也能满足基础的用户-业务数据绑定需求。

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