DynamoDB一对多和多对多结构

Question

我对DynamoDB还是陌生的，并试图理解关系。

我有一个包含用户，列表和项目的待办事项应用程序。

我创建了3个dynamoDB表，一个用于用户，一个用于列表，一个用于项目。

为简单起见，以用户/列表为例。用户的主键是userId。列表主键是listId。用户可以有很多列表。列表可以在用户之间共享，因此列表可以有许多用户。

那么，列表应该作为listId的数组保存在用户项中吗？然后，当我得到一个用户时，我遍历listId的数组并获取所有列表？

用户可以有很多列表，而列表又可以有很多项目，因此我不想将整个列表保存在用户项目中。该列表也可以被许多用户共享。

我已经尝试搜索关系，但是它们似乎都是从读者对NOSQL数据库有广泛理解的假设开始的，而我没有。

Answer 1

我认为，一对多关系是DynamoDB的优势之一。在您的示例中，列表与其项目之间存在一对多关系。要在Dynamo中进行建模，可以说您拥有一个类似于以下内容的Item模式

{
  itemId: String,
  listId: String,
  name: String
}

您可以使用哈希键创建项目表itemId。这样一来，您就可以对单个商品执行所有标准的CRUD操作。

如果我们还创建了一个Hash键为listId，Sort键为的Global Secondary Index itemId，则可以查询给定列表中的所有项目。

在这种情况下，全球二级索引为我们提供了列表与其项目之间的一对多关系。您也可以将其视为按其将项分组listId。

多对多关系很艰难。通常，它们要求您在进行多个查询和复制数据之间做出决定。在这两种情况下，开始的一个好方法可能是使用以下简单模式创建UserList表

{
  userId: String,
  listId: String
}

使用userId作为您的哈希键，并listId为您的排序键。您可以认为此表具有按用户ID分组的列表ID。然后，您可以使用listIdHash键和userIdSort键来创建Global Secondary Index 。这将为您提供按列表ID分组的用户ID。该表及其GSI组合为您提供了多对多关系。

当然，如果对多对多关系使用此方法，则需要向User和/或List表发出请求，以获取这些对象的实际数据。要对此进行优化，您需要将User和/或List数据复制到UserList表中。

在Dynamo中，还有许多其他方法可以处理多对多关系，但这是一个很好的起点。