采用AWS Cognito后，是否可省去数据库内的传统users表？

嘿，先给你个明确的答案：完全不需要放弃自己的 users 表，反而绝大多数实际项目里都会保留它——毕竟你要和组织、留言板这些业务表做关联查询，Cognito本质是个身份认证工具，管的是用户“能不能登录”，而业务数据的关联逻辑，还是得靠自己的数据库来搞定。

接下来我用最直白的方式给你拆解问题：

1. 为啥不能用 Cognito 用户组来做业务关联？ #

Cognito 的用户组（User Groups）是用来做权限控制的——比如区分“管理员”和“普通用户”，让某些接口只有管理员能调用。但它完全不是为业务关联设计的：

• 它没法像 SQL 那样做多对多、多对一的复杂关联查询；
• 你没法在用户组里存储“用户属于哪个组织”“用户发过哪些留言”这类业务关系数据；
• 用它来做业务关联，后期维护会超级头疼，完全不符合业务逻辑的设计思路。

2. 怎么让自有 Users 表和 Cognito 保持同步？ #

这是最核心的解决方案，有几个简单易上手的方法：

• 用 Cognito 触发器自动同步（首推）
  Cognito 自带各种触发器，比如用户注册并确认邮箱后的「Post Confirmation」触发器，你可以给它绑定一个 Lambda 函数——用户注册成功后，Lambda 会自动把 Cognito 里的用户唯一标识（sub 字段，这个是每个 Cognito 用户的专属ID）、邮箱、用户名同步到你的 users 表里。
  举个直观的例子：Lambda 里执行一句 SQL 就能搞定：

  INSERT INTO users (cognito_sub, email, username) VALUES ('用户的sub值', 'user@example.com', '用户名');
  

  如果用户后来改了邮箱，你也可以用「Pre Sign-up」或者「User Migration」触发器来同步更新自有表。
• 登录时补全同步
  要是有老用户（之前在自有表有记录，后来才迁移到 Cognito），可以在用户每次登录成功后，用 Cognito 返回的最新用户信息，更新自有表的对应字段（比如邮箱、手机号）。
• 定期同步（应急用）
  可以开个 Lambda 定时任务（比如每天跑一次），调用 Cognito 的 ListUsers API 拉取所有用户，和自有表比对，补全漏同步的记录或者更新变更的信息——这个主要是用来处理触发器偶尔没触发成功的异常情况。

3. 业务关联查询该怎么做？ #

你的 users 表一定要把 Cognito 的 sub 字段作为核心关联标识：

• 比如组织表可以通过中间表（多对多）关联 users 表的 cognito_sub 和组织表的 id；
• 留言板表可以直接加个 author_sub 字段，关联 users 表的 cognito_sub。
  举个查询的例子，要查某个用户所属的组织和他发的留言：

  SELECT u.username, o.org_name, b.post_content
  FROM users u
  JOIN user_org_relation ur ON u.cognito_sub = ur.user_sub
  JOIN organizations o ON ur.org_id = o.id
  JOIN bulletin_boards b ON u.cognito_sub = b.author_sub
  WHERE u.cognito_sub = '某个用户的sub值';
  

4. 授权相关的小技巧 #

如果你需要根据用户的业务角色（比如“某组织管理员”）做授权，可以在自有 users 表或者组织关联表里存角色信息，然后用 Cognito 的「Pre Token Generation」触发器，把这些角色信息加到用户登录后拿到的 Token 里——这样后端服务拿到 Token 就能直接判断权限，不用每次都查数据库，省事儿很多。

最后想说，知道你现在既要工作学习又要照顾新生儿，时间精力肯定特别紧张，这些方案都是成熟且容易上手的，先从「Post Confirmation 触发器同步」开始做，一步步来就行，不用着急~

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