在单表数据库中创建分区键列表答案

【问题标题】：Creating a list of partition keys in a single-table database在单表数据库中创建分区键列表
【发布时间】：2021-05-04 07:20:36
【问题描述】：

我是 dynamoDB 和非 SQL 数据库的新手，正在努力设计。

我正在尝试为学校中的部门和部门每周安排的应用程序建模。最终，我想提供一个前端，用户可以在其中对部门执行 CRUD 操作——最初，如果部门只有一个名称就可以了。部门日程表由可以嵌入网页的 HTML 片段表示。部门日程安排在一年中的不同时间发生变化，并且在假期的几周内也会发生变化。对于给定的部门，我希望能够存储定义最常见每周时间表的模板，类似于“2021 夏季常规时间”。然后可以将这些每周模板复制到某个部门以用于一周的实际计划，例如“2021 小时 5 月 20210509”。

我的应用程序需要的数据访问是（从最常见到最少列出）：

获取部门的每周计划
部门的 CRUD 每周计划。
部门的 CRUD 每周模板。
列出部门。
CRUD 部门。

我一直在摆弄一个带有单个表的本地 dynamoDB 数据库。我最终得到了这个：

PK           SK                                  Attributes
============ ===============                     ==========
DEPT#Library PROFILE#Library                     { "departmentName": "Library", ... }
DEPT#Library TEMPLATE#2021 Summer Regular Hours  { "departmentName": "Library",
                                                   "templateName": "2021 Summer Regular Hours",
                                                   "templateDisplay": "<table><tr><td>Sunday</td><td>1:00pm-5:00pm</td></tr>...</table>"}
DEPT#Library SCHEDULE#2021-05-09                 { "departmentName": "Library",
                                                   "scheduleName": "2021-05-09",
                                                   "scheduleDisplay": "<table>...</table>"}

在我看到一个设计单个表来保存各种信息的示例之后，我打算将我的分区键和排序键命名为“PK”和“SK”。我不确定这是否是好的形式。

我认为这适用于我的大多数数据访问模式。但我一直在想出一个列出部门的好解决方案时遇到问题。我想出的是定义一个全局二级索引departmentNameIndex，AttributeName为departmentName，KeyType为HASH，ProjectionType为KEYS_ONLY。这确实允许我通过索引扫描表并检索所有部门名称。对 dynamoDB 中的表进行“扫描”是不是很糟糕？有没有更简单的方法可以达到同样的目的？

谢谢。

【问题讨论】：

标签： amazon-dynamodb

【解决方案1】：

您的第一个 NoSQL 数据建模练习做得很好，干得好！

我打算将我的分区键和排序键命名为“PK”和“SK”......我不确定这是否是好的形式。

这不仅是一种很好的形式，而且我认为这是一种最佳做法。

我一直在想出一个好的解决方案来列出问题部门。我想出的是定义一个全局二级 index，departmentNameIndex，AttributeName为departmentName， HASH 的 KeyType 和 KEYS_ONLY 的 ProjectionType。这确实允许我通过索引扫描表并检索所有部门名称。

这是一个完全合理的方法。您所描述的模式称为“稀疏索引”，因为并非表中的每个项目都有departmentName。因此，您的二级索引是主表中数据的子集（而不是在二级索引中复制表中的每个项目）。

对 dynamoDB 中的表进行“扫描”是不是很糟糕？

扫描本身既不好也不坏。这是一个强大的工具，可以用来做getItem 和query 不能做的事情。像任何工具一样，它在坏人手中可能是危险的。我认为应该谨慎使用scan，并且只有在您确定自己了解自己在做什么的情况下才可以使用。

在一些用例中使用scan 是完全合理的。稀疏索引就是这样一种情况。另一个体面的用例是当您不经常运行的操作（例如每周指标收集/季度报告/等）不能证明额外的数据建模“成本”用于您的数据模型时。

有没有更简单的方法可以达到同样的目的？

DynamoDB 在定义数据模型方面为您提供了吨的灵活性。在确定特定的数据模型之前，您可能会经历多次迭代；这是一个过程。你在正确的道路上，继续前进！

【讨论】：