如何在DynamoDB中为多对多关系实现单表设计建模

首先先纠正你第一个访问模式的键设计问题：你现在用CardId当PK、UserId当SK，只能支持按卡片ID查所属用户，要拉取某个用户的全部所属卡片得全表扫描过滤，性能根本扛不住，这个设计得调。
单表设计根本不需要像关系型数据库那样单独建关联表，核心逻辑是把同查询场景的条目塞到同一个分区键下，用排序键前缀区分条目类型，靠字段冗余减少二次查询，完全能覆盖你说的三个业务场景，具体设计如下：

基础表规则 #

主表统一用PK、SK作为主键字段，不要直接拿业务字段名当主键，加个type字段标记条目类别，所有实体、关联关系全存在这一张表里：

• 卡片实体：PK = CARD#${CardId}，SK = METADATA#${CardId}，存CardId、所属UserId、卡片名称等所有卡片固有属性
• 股票持仓实体：PK = STOCK#${CardId}#${UserId}，SK = METADATA#${Timestamp}，存CardId、UserId、Price、Quantity、Timestamp等持仓全量属性
• 用户发布卡片关联：PK = USER#${UserId}，SK = LISTING#CARD#${CardId}，冗余卡片名称、封面等列表页常用字段
• 用户关注卡片关联：PK = USER#${UserId}，SK = WATCHING#CARD#${CardId}，同样冗余卡片常用展示字段
• 用户持仓关联：PK = USER#${UserId}，SK = HOLDING#STOCK#${CardId}，冗余Price、Quantity等持仓列表要展示的字段

如果后续需要反向查（比如查某张卡片的所有关注者、所有持仓人），只要加一个GSI，把GSI的映射规则设为：卡片类关联条目的GSI-PK取对应CardId、GSI-SK取对应用户Id即可，不需要改表结构。

三个业务场景的查询方式 #

• 获取指定用户所属的卡片列表：直接查主表，指定PK = USER#${目标用户ID}，用begins_with匹配SK前缀LISTING#CARD#，一次查询就能拿到全量列表，因为提前冗余了常用字段，大部分场景不需要再回查卡片实体；如果要拿卡片全量属性，拿到结果里的CardId后批量查对应CARD#${CardId}的实体条目就行，主键批量查询的延迟非常低。
• 获取指定用户正在关注的卡片列表：逻辑和上面完全一致，同样查对应用户ID的PK分区，用begins_with匹配SK前缀WATCHING#CARD#即可，不需要建额外的关联表，也不需要走GSI。
• 获取指定用户持有的股票列表：还是同一个逻辑，查对应用户ID的PK分区，匹配SK前缀HOLDING#STOCK#就能直接拿到列表，因为已经冗余了价格、数量这些展示字段，连股票实体都不用单独查；如果需要单条持仓的明细（比如历史交易记录），再拿CardId和UserId去查对应的股票实体条目就行。

关于你提到的「CardId设为PK、UserId设为SK返回不同类型条目」的思路 #

这个思路是对的，但适用场景是你需要高频按卡片维度查关联数据——比如查某张卡片的所有关注者、所有持仓人，这时候把这些关联条目存在CARD#${CardId}的分区下，SK用WATCHER#${UserId}、HOLDER#${UserId}做区分就可以。
单表设计没有标准答案，核心原则就一个：你要一起查的数据，就放到同一个分区键下，不要硬套关系型数据库的三范式拆表，常用的展示字段直接冗余在关联条目里，尽量一次查询拿回所有需要的数据，这才是单表设计性能优势的来源。

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