database - 在什么情况下你会在 DynamoDB 上使用 Simple Hash Keys？

Question

Simple Hash Keys 写文章好像太简单了，而写Composite Hash/Range Keys的很多，因为Composite Hash/Range Keys对很多复杂的情况都有用。但是我相信在一般的应用中，很多表应该是用Simple Hash Keys来设计的。你在什么情况下使用简单哈希键？

例如，当你设计如下层次模型时，你如何为每个表设计主键？ (除 Tenant 之外的所有表都将 tenant_id 作为字段。)

• 租客
• 用户
• 团队
• 项目
• 任务
• 团队成员

想法1

只有“Team Member”是Composite Hash/Range Key设计的。其他由Simple Hash Key设计。

想法。 2

• Tenant 由 Simple Hash Key 设计。
• 用户、团队和项目的主键将是复合的(tenant_id、sub_id)。
• 任务的主键是复合的({tenant_id}_{project_range_key}, sub_id)。
• 团队成员的主键是复合键({tenant_id}_{team_range_key}、{tenant_id}_{user_range_key})。

其中 sub_id 可以是序号、created_at 或其他。

更新

发布这个问题后，我对 DynamoDB 及其历史有了更多的了解，现在我清楚地认识到了我的担忧。

在 Amazon 发布 GSI 之前，我们不得不设计像“Idea 2”这样的表来查询“tenant_id”。但现在我们可以使用 GSI，因此我们可以使用“简单哈希键和 GSI”的组合来设计表(例如团队、项目或任务)。是对的吗？？

Answer 1

您使用单个哈希键表来描述一个项目。例如，一个用户有很多信息，如姓名、年龄等。您可以创建一个用户表，其中 user_id 作为 hashkey，所有其他信息作为属性。

您使用散列范围架构来描述关系。例如，一个团队可以有多个用户。因此，您可以创建一个团队成员关系表，其中团队 ID 作为散列键，用户 ID 作为范围键。

换句话说，画一个关系图，顶点是(用户、团队、项目)，边是他们的关系(1对1、1对多、多对多等)。然后对顶点使用 Hashkey 模式，对边使用 Hash-Range 模式。

谢谢!

二本