我是 DynamoDB 的新手，我正在尝试创建一个 DynamoDB 设计来表示以下关系：
我想提供的查询是用户是否有内容。如您所见，用户可能直接或通过内容集合拥有内容。我可能可以创建一个表并执行以下操作：
但是，问题是当我想知道用户 1 是否有内容 3 时，我需要进行两次查询。有没有更好的策略在单个查询中处理这个问题？
一些注意事项：
【问题讨论】：
标签： database-design nosql amazon-dynamodb database-schema
为了防止多次查询，您还需要将 Content#3 放在 User#1 PK 下，例如 `SK: CONTENTCOLLECTION#2' 属性 #CONTENT#3"
当然，这很快就会变得非常笨拙。多对多是一种在 Dynamo 中不太容易复制的关系。它也可能导致更多的写入，但这通常是可以的，因为在大多数情况下，写入通常比读取更便宜/更快（经验法则：2 次写入是可以的，2 次读取不是 - 你似乎已经明白了）
事实上，您的数据是在存储优先的解决方案中设计的——也就是说，您认为最好有一个对象类型的用户、一个内容和一个内容集合。对于一般情况，这一切都很好而且很花哨 - 对于 SQL 数据库来说也很好，但是当您尝试将单个访问模式强加到它上面时，它就会崩溃。
您的问题一开始就进一步强化了这一点：您想创建一个发电机模式来适应这种数据关系模式。相反，您应该问：我将拥有这条信息并且我希望能够获得这些东西 - 我如何设计我的发电机模式来促进这一点？
您可能需要重新考虑您的访问模式并在此基础上设计您的发电机模式。这是一种更难思考的方式 - 特别是如果您有设计 SQL 数据库的历史，并且 做得最好的是存储优先而不是访问优先。
这里没有足够的信息让我真正给出更好的访问模式的好答案，但你可能会考虑为什么你有 Content 和 ContentCollection。
如果您希望能够通过某种标记存储数据，您可以使用稀疏索引 - 即，Content#1 具有 ContentCollection#1: True 和 ContentCollection#2 True 的属性 - 但 Content#2 没有t 甚至有属性 ContentCollection#1 因为它不是它的一部分。由 ContentCollection#1 形成的稀疏索引将为您提供其中的所有内容。当然，如果您还拥有多个内容集合，这可能会变得非常笨拙。但也许它会激励你。
无论您以何种方式对其进行切片，尝试执行这种多对多关系都会导致每个 User/ContentCollection 或两个查询上的附加属性的复杂性呈指数级增长。
【讨论】：