单表DynamoDB预订系统设计咨询：替代Postgres RDS可行性

一、现有单表设计的核心修正 #

你的当前设计存在DynamoDB规则冲突：所有记录必须包含Partition Key（Pk），不能为空。结合数据层级关系（企业→联系人→预订），建议采用**复合主键（Pk + Sk）**来组织数据，修正后的结构示例如下：

修正后单表结构 #

注：时间字段统一用YYYY-MM-DDTHH:MM:SS的ISO 8601格式，方便排序和范围查询；空属性无需写入，节省存储空间。

二、各访问模式的实现方案 #

针对你的业务场景，逐一给出具体操作逻辑：

1. 按ID获取企业
   使用GetItem直接查询，主键组合为Pk = BUSINESS#<企业ID> + Sk = METADATA

   dynamodb_client.get_item(
       TableName='BookingsSystem',
       Key={
           'Pk': {'S': 'BUSINESS#123'},
           'Sk': {'S': 'METADATA'}
       }
   )
   

2. 获取企业联系人
   使用Query操作，匹配企业Pk并筛选Sk前缀

   dynamodb_client.query(
       TableName='BookingsSystem',
       KeyConditionExpression='Pk = :pk AND begins_with(Sk, :sk_prefix)',
       ExpressionAttributeValues={
           ':pk': {'S': 'BUSINESS#123'},
           ':sk_prefix': {'S': 'CONTACT#'}
       }
   )
   

3. 获取企业预订
   逻辑同联系人查询，将Sk前缀改为BOOKING#；若需按时间排序，可将Sk设为BOOKING#<ISO开始时间>#<预订ID>，查询时直接按Sk排序即可。

4. 按ID获取联系人
   创建全局二级索引（GSI），将索引Pk设为ContactId（即联系人的id字段），通过Query该GSI直接获取；或插入反向记录Pk = CONTACT#<联系人ID> + Sk = BUSINESS#<企业ID>，用GetItem快速查询并关联所属企业。

5. 获取联系人的预订
   创建GSI，将索引Pk设为RequesterId，Sk设为原表的Sk（BOOKING#xxx），查询该GSI即可直接获取该联系人的所有预订；若数据量极小，也可先获取联系人所属企业ID，再查询企业下的预订并过滤，但不推荐此方案。

6. 按ID获取预订
   同联系人查询逻辑，创建GSI将索引Pk设为BookingId，或插入反向记录Pk = BOOKING#<预订ID> + Sk = BUSINESS#<企业ID>，通过GetItem直接获取。

7. 搜索所有企业的即将到来的预订
   创建GSI，设置：

   • 索引Pk为固定值UPCOMING_BOOKINGS（跨企业查询用同一分区键）
   • 索引Sk为ISO开始时间#<预订ID>
     查询时匹配Pk = UPCOMING_BOOKINGS且Sk > 当前时间ISO格式，即可按时间顺序获取所有即将到来的预订。你的数据量极小，该方案完全不会有性能问题。

三、关于ID分配与单表/多表的疑问解答 #

1. ID分配是否过度关系型？
   给联系人、预订分配独立ID是合理的，无需纠结关系型思维——DynamoDB中ID的作用是唯一标识记录，配合主键结构和GSI即可实现关联查询，不需要外键约束。

2. 单表还是多表？
   单表设计完全适合你的场景：数据层级明确，单表可通过一次Query获取企业关联的所有联系人/预订，减少网络请求；数据量小，单表无管理负担。拆分多表反而会增加关联查询复杂度，没必要。

四、额外优化建议 #

• 按需创建GSI：仅针对必要的访问模式创建，避免冗余索引浪费资源
• 避免存储空属性：DynamoDB自动忽略空属性，无需主动写入
• 主键命名规范：用ENTITY#ID的格式明确区分不同类型的记录，提升可读性

内容的提问来源于stack exchange，提问作者steve.w