RDBMS背景开发者求助：多索引NoSQL数据库设计（偏好DynamoDB）

一、多维度查询的索引设计 #

Users表 #

• 主键设计：主分区键设为organisation_id，主排序键设为user_id，直接支持按组织查询用户的需求。
• 全局二级索引（GSI）配置：
  • 针对email/username精准查询：分别创建GSI，分区键为email（或username），排序键为user_id。利用这两个字段的唯一性，快速定位单个用户。
  • 针对按课程/单元查询用户：创建两个GSI，一个分区键为course_id、排序键为user_id；另一个分区键为unit_id、排序键为user_id。如果需要关联更多属性，可将organisation_id、user_details等设为投影属性。

Courses表 #

• 主键设计：主分区键设为organisation_id，主排序键设为course_id，原生支持按组织查询课程的需求。
• 若需按课程名称模糊/精准查询：创建GSI，分区键为course_name，排序键为course_id（避免名称重复导致的冲突）。

二、报表场景：查询课程下未完成状态的用户 #

推荐两种高效方案：

1. GSI+状态字段
   在用户-课程关联记录（可放在Users表的属性里，或单独建关联表）中添加course_completion_status字段（值为completed/uncompleted）。创建GSI，分区键为course_id，排序键为user_id，并投影course_completion_status与用户核心信息。查询时直接指定GSI，过滤course_completion_status = 'uncompleted'即可。

   注意：若数据量极大，过滤操作会占用较多读取容量，此时更推荐第二种方案。

2. 物化视图（预聚合表）
   用Lambda触发同步机制：当用户的课程完成状态更新时，自动同步到专门的报表表。表结构设计为：分区键course_id，排序键user_id，属性包含completion_status、user_name、email等报表所需字段。查询时直接扫描该表的course_id分区，无需过滤，性能最优。

三、NoSQL设计学习资源（无外链） #

• AWS DynamoDB官方文档的「数据模型设计」「索引最佳实践」章节，重点研究单表设计模式，里面包含电商、在线教育等场景的实战示例。
• 单表设计经典案例：将Organisation、Users、Courses、Units整合到一张表，用item_type（如ORG/USER/COURSE/UNIT）作为分区键前缀，排序键设计为ORG#<org_id>、USER#<user_id>、COURSE#<course_id>#USER#<user_id>等，实现多维度关联查询。
• 多对多场景示例：用户与课程的关联用单独表项存储，属性包含user_id、course_id、completion_status、enroll_time等，满足关联查询与状态统计需求。
• DynamoDB官方工作坊内容：包含 step-by-step 的设计练习，比如在线课程平台的完整设计流程，覆盖CRUD、多维度查询、报表生成等核心场景。

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