1

我们有一个 REST API，其中一部分显示用户的“目录”。目录是产品列表以及一些整体目录元数据（例如剩余金额）。

我们正处于尝试将此元数据添加到目录响应的阶段，但被困在我们的数据库设计上。后备存储是 Amazon 的 DynamoDB，它只是一个键值存储。值得注意的是，它支持主键（“哈希”）和辅助键（“范围”）。

目前我们的数据库条目如下所示：

{ customerId: "xxx", productId: "yyyy", productPrice: "zzz" }

我们可以或多或少地直接将这些翻译成目录条目，从而产生以下响应

{ products: [{ id: "yyyy", price: "zzz" }] }

但是我们现在想要一个带有元数据的响应，比如

{ metadata: { moneyLeft: 5 }, products: [{ id: "yyyy", price: "zzz" }] }

问题是，我们如何将元数据存储在我们的数据库中？

方法 #1：分离数据库

创建一个单独的元数据表，其中包含customerId所有元数据属性的主键和列。然后查询两个表（对 DynamoDB 的两个 HTTP 请求），并组合结果。

方法#2：面向查询

重新调整当前表的用途，使其专为此目录显示查询而设计。它将有两种类型的行，例如

{ customerId: "xxx", productId: "yyyy", productPrice: "zzz", type: "product" }
{ customerId: "xxx", moneyLeft: 5, type: "metadata" }

（虽然更强大一点）。然后我们可以使用 查询从表中选择所有行，并在我们的服务器代码中通过打开属性customerId = xxx将它们转换为所需的响应。type

我倾向于方法#2，因为方法#1 似乎仍然停留在关系数据库思维中，并且它会涉及两个数据库调用（= HTTP 请求）。但这太奇怪了，我不确定这是个好主意。也许有第三种方法？我想真正的答案是“你应该使用文档数据库”，但我们现在非常致力于 DynamoDB -_-。

4

1 回答 1

0

表的范围键是什么？我假设哈希键是 customerId...
总的来说，在考虑 NoSQL 解决方案时，我发现自己在想“我要查询什么”
如果您的查询始终是“查询所有带有 customerId = XXX 的项目”，那么我认为是糟糕的设计将另一个“元数据”项目滑到那里。
更健壮和浪费的方法是将元数据连接到所有项目中，但这在更新方面本身就有缺点。（我也不推荐它）
我认为即使它听起来像一种关系方法，在你的场景中我会坚持使用另一个表。
此外，通过部分了解您的数据库，我仍然认为查询用户的元数据而不实际查询他的目录是有意义的。

于 2012-06-25T08:20:40.913 回答