DynamoDB单表设计中GSI插入的属性命名与重复存储疑问

你的理解方向是对的，但这里有个关键误区——不需要额外创建GSI-PK/GSI-SK这类字段，直接用已有的业务属性作为GSI的键即可，这能同时解决可读性和数据冗余的问题。

核心结论 #

DynamoDB单表设计确实允许适度的数据冗余（为了查询效率牺牲关系型数据库的范式），但你当前的两种方式都不是最优解：

• 第一种方式的可读性问题会直接拉高团队维护成本，后续开发者很难关联抽象的GSI字段和业务含义，完全不推荐
• 第二种方式的冗余是没必要的，因为GSI可以直接绑定已存在的业务属性

正确的实现方式 #

创建GSI时，直接指定entity_type作为GSI的分区键（HASH），order_date作为GSI的排序键（RANGE），不需要额外存储GSI-PK/GSI-SK。插入数据时只需要保留业务核心属性即可：

dynamodb.put_item(
    TableName='YourTableName',
    Item={
        'pk': {'S': 'O#123'},
        'sk': {'S': 'C#456'},
        'order_name': {'S': 'test'},
        'order_date': {'S': 'xx-xx-xx'},
        'entity_type': {'S': 'order'},
    }
)

为什么这是最优解？ #

1. 可读性拉满：entity_type和order_date都是有明确业务含义的字段，其他开发者一眼就能看懂GSI的作用（按实体类型+订单日期排序查询）
2. 无冗余数据：不需要重复存储相同的属性值，GSI会自动同步指定的属性作为索引键
3. 避免稀疏索引的查询混乱：所有实体都保留entity_type字段，无论是查主表还是GSI，识别实体类型的逻辑是统一的

额外提示 #

如果后续需要新增其他GSI，同样遵循这个原则：直接绑定已有的业务属性作为GSI的键，不要创建新的抽象命名字段。比如要做一个按客户ID+订单日期的索引，就用customer_id作为GSI分区键，order_date作为排序键即可。

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