在 couchbase 中建模数据答案

【问题标题】：Modeling data in couchbase在 couchbase 中建模数据
【发布时间】：2019-12-08 18:13:12
【问题描述】：

我们正在尝试使用 Couchbase 作为 API 的后端。而 Api URL 是这样的。

http://someserver/{Product}/{Id}

product 和 Id 会随着每个请求而改变。

每个产品都有自己的数据集，对于不同的 id 也同样适用

我的第一个想法是为每个产品和 id 都有一个文档，这意味着

文档 1:- product-1 Doc2:- product-2 等等..

文档 n:- id-1 文档 n+1:- id-2

但是当我们重新审视业务问题时，我们可以有 6 个可能的产品值和 1000 多个 Id 值，这些值很快就会增长到很多。通过上述方法，我们最终会得到很多文档。

并且每个 ID 都会有一个与之关联的产品。这意味着对于每个 ID，目前有 6 个可能的产品。

那么任何人都可以建议对这些数据进行建模的有效方法。

【问题讨论】：

一个 ID 是否只能关联一个产品，还是一个 ID 可以关联多个产品（现在和将来）？
当我用商业术语说 ID 时，他们实际上是合作伙伴，每个合作伙伴都有多种产品。因此，当 API 请求带有此 URL /Energy/100 时，所有 API 都必须为合作伙伴 100 及其产品获取数据

标签： .net nosql couchbase data-modeling

【解决方案1】：

我认为拥有大量文档可能会占用空间，但除非您在每个 ID 文档中直接包含产品数据，否则我认为没有很多其他实用的建模方法。就拥有大量文档的缺点而言，显然会有存储成本（但这不应该真的超过任何其他模型，因为您仍然需要存储相同数量的数据，但是您对其建模，以及其他除了大量离散文档之外的其他方法可能会导致重复数据），以及在存储桶上使用视图时需要考虑的因素。

如果您有足够的存储空间（和内存，对于您通常需要的一组活动数据），并且注意您对视图的使用，我想不出一种出色的数据建模方式。许多文档可能看起来效率低下，但从结构的角度来看它是合乎逻辑的。关于唯一硬性和快速的建议是确保 Product 文档用于每个 id 的引用（反之亦然）引用该文档的密钥（即，document uid）而不是被引用文档的一些更易读的字段（尽管，如果值是唯一的，这样的字段可以用作文档 uid 的（部分）。

一个示例文档是（例如product::abc）：

{
    "id" = "product::abc",
    "name" = "abc",
    "type" = "xyz",
    "partners" = [
        "partner::abc", "partner::def", ..., "partney::xyz"
    ]
}

然后对于partner::abc：

{
    "id" = "partner::abc",
    "name" = "abc",
    "location" = "xyz"
}

【讨论】：