我仍在争论该走哪条路，并可能在其自己的文档中存储某些信息。因此，例如，客户可以拥有一个地址，每个地址将是其自己的doc，然后在客户doc中将在地址下存储一组引用键。好处是我可以仅根据键值来更新这些文档，而不必先获取客户文档，找到地址的数组索引，然后修改整个文档，或者使用子文档替换数组内容与索引。 我遇到的问题是如何检索那些引用的子文档。是N1QL唯一的解决方法，还是KV API提供了一种方法来做到这一点，即检索整个客户文档，然后遍历地址数组并以这种方式检索所有引用的文档。我知道奥斯曼提供了类似的功能，但由于最新版本的SDK 2.6和奥斯曼没有很好的维护，我遇到了问题。因此，希望有人可以分享一些见解，以及为什么这是最好的方法。
答案 0 :(得分：1)
如果要依赖键/值，则需要按照描述进行多次查找。我对奥斯曼帝国不是很熟悉：可能可以为您做到这一点，但在幕后仍然会存在多个键/值操作和/或N1QL。
使用N1QL，您可以执行JOIN，但是同样，在幕后它最终将根据键/值来提取文档。它只是为您完成了这些额外的步骤。直接键/值始终是最快的方法。
如果您仍在决定是在多个文档之间拆分数据还是将数据“非规范化”为单个文档，那么您应该考虑的事情是您将经常访问客户+地址的频率以及您分别去客户/访问的频率。如果您经常读/写客户+地址，请考虑将其放在一个文档中。否则，请考虑将其放入多个文档中。
第三个选项是将其存储在两个位置，或者更确切地说，将地址数据“缓存”在客户文档中。这很棘手，因为如果不小心，它可能会不同步。因此，在走那条路之前，请确保它值得。