Dynamodb模式设计（将关系数据映射到nosql）

Question

我想了解一下这个例子，从AWS映射关系模型到nosql

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

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

重要的

.... 大多数设计良好的应用程序只需要一个表。。。

因此，示例表如下

它解释了，

您可以定义以下实体，这些实体支持关系订单条目模式：

HR员工-主键：员工ID，主键：员工姓名

HR区域-主键：区域ID，主键：区域名称

...

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

此外，它建议以下查询

但是GSI-1没有员工名的PK。

我理解这可能是AWS文档中的一个差异，我应该向他们提出（我有，他们在后续工作中表现得非常糟糕），但我不确定的是文档是否正确，我的理解是否错误（我倾向于相信后者，因为AWS文档通常是准确的）。

有人能在nosql模式映射方面为我指明正确的方向吗？对于上面链接中的模式，一个正确的示例（带有dynamo表的示例记录）将非常有价值。

Answer 1

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

首先，您提到以下事实：

但是，示例表中的实体HR-雇员-PK：雇员ID、SK：雇员名称的SK值不是雇员名称。

存在不是“员工姓名”的SK值的原因是，SK不仅用于“员工姓名”，还用于其他查询（如地区名称、国家名称等）。把SK想象成它的确切含义，一个排序键。文档中似乎没有解释额外的SK，所以让我总结一下您所看到的内容。

您有HR-Employee1，员工姓名=Employee1，QuotaID（猜猜这个键是什么）=配额-2017-Q1，其他一些键=HR-机密

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

这允许您使用employeeID作为主键、EmployeeName作为主键来查询员工数据，但也允许您使用employeeID作为主键、QuoteAid作为主键来查询员工配额数据（或其他数据）。

关于GSI-1的第二个问题也是如此。本质上，在这个场景中，他们设计表的方式是使用一个SK“SortKey”，在这里可以有各种类型的值进行排序，如果这样做有意义的话。