amazon-web-services - Dynamodb 架构设计（将关系数据映射到 nosql）

Question

试图从 AWS 中了解这个示例，将关系模型映射到 nosql

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-modeling-nosql-B.html

这里强调的一个关键概念是：

重要的

.... 大多数精心设计的应用程序只需要一张表。...

鉴于此，示例表如下

它解释说，

您定义以下支持关系订单输入模式的实体：

HR-员工 - PK：员工 ID，SK：员工姓名

HR-Region - PK：RegionID，SK：区域名称

...

HR-Employee - PK: EmployeeID, SK: Employee Name但是，示例表中的实体的SK值不是Employee Names。

此外，它建议以下查询

但 GSI-1 没有Employee Name.

我知道这可能是 AWS 文档中的一个差异，我应该向他们提出（我有，而且他们在跟进方面出了名的糟糕）但我不确定文档是否正确并且我的理解是否错误（我'我倾向于相信后者，因为 AWS 文档通常是准确的）。

有人可以指导我在 nosql 模式映射方面的正确方向吗？上述链接中模式的正确示例（带有发电机表的示例记录）将非常有价值。

标签： amazon-web-servicesnosqlamazon-dynamodb

Answer 1

所以我会试着让你更清楚，让我知道如果有些事情仍然没有意义。

首先，您提到以下事实：

但是，示例表中的实体 HR-Employee - PK: EmployeeID, SK: Employee Name 的 SK 值不是 Employee Names。

SK 值不是“Employee Names”的原因是因为 SK 不仅用于“Employee Names”，还用于其他查询（例如 Region Name、Country Name 等）。将 SK 视为它所代表的确切含义，即排序键。文档似乎错过了他们拥有的额外 SK 的解释，所以让我总结一下你在看什么。

您有 HR-Employee1，员工姓名 = Employee1，QuotaID（猜猜这个键是什么）= QUOTA-2017-Q1，其他键 = HR-CONFIDENTIAL

这些键名实际上并没有在表中定义，它们都在排序键下，并且只是隐含的“员工名称”或“配额ID”或“区域名称”。

这允许您做的是查询员工数据，使用employeeID 作为PK 和员工姓名作为SK，但它还允许您通过使用employeeID 作为PK 和quotaID 作为SK 查询员工配额数据（或任何它）。

这同样适用于您关于 GSI-1 的第二个问题。本质上，他们在这种情况下设计表格的方式是您有一个 SK“SortKey”，如果有意义的话，您可以在其中对各种类型的值进行排序。