根据DynamoDB文档：https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html，“在DynamoDB应用程序中，您应该尽可能少地维护表格。大多数良好设计的应用程序仅需要一个表。”
但是根据我的经验，由于分区键设计，您总是需要做相反的事情。
让我们考虑下一个情况。我们有几个用户角色，例如“管理员”，“经理”，“工人”。管理员的常规工作流程是CRUD管理器数据，其中读取操作是获取所有管理器列表而不是一个管理器。对于经理也是同样，他会CRUD工人数据。对于这两种情况，我们只有两种关键字使用场景：
我觉得我根本不理解这个概念。如何才能以只使用一个 DynamoDB 表格来有效地使用提供的示例的键模式？
但是根据我的经验，由于分区键设计，您总是需要做相反的事情。
让我们考虑下一个情况。我们有几个用户角色，例如“管理员”，“经理”，“工人”。管理员的常规工作流程是CRUD管理器数据，其中读取操作是获取所有管理器列表而不是一个管理器。对于经理也是同样，他会CRUD工人数据。对于这两种情况，我们只有两种关键字使用场景：
- 获取所有项目的列表（项键无关紧要）
- 使用其完整键与特定项目一起工作。
根据文档的强调，我们应该有一个均匀分布的分区键，因此不能选择用户角色，而应该使用用户ID。由于我们已经有了一些随机ID作为分区键，因此我们根本不需要排序键，因为它根本不起作用 - 我们只使用分区键部分就能访问到一个用户。此时，我们意识到对于每个R操作，需要扫描整个表格，然后通过用户角色来过滤结果，这是低效的。那么如何改进呢？非常自然的方法是-让我们为每种用户类型都拥有自己的表格！然后我们将从管理员API扫描经理列表，并从经理列表中扫描工人列表。
我使用 DynamoDB 已经一年了，但仍然无法理解它。对我来说，实际上，对于真实生活场景，排序键是你永远无法使用的东西（我唯一使用过它的真实情况是访问像“协议”这样属于两个不同类型用户的项目，所以主键为{ partition: "managerId", sort: "userId" }，并且辅助全局索引为{ partition: "userId", sort: "managerId" }，因此我可以有效地查询所有特定管理员协议列表或所有特定用户协议列表，只提供相应的管理员或用户 ID 进行查询。该方法在此文档中讨论：https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html）。我觉得我根本不理解这个概念。如何才能以只使用一个 DynamoDB 表格来有效地使用提供的示例的键模式？