我正在考虑一个将存储客户数据的应用程序。鉴于存储桶在 CouchBase 中的工作方式，所有客户数据都将位于一个存储桶中。看来我有两个选择：
通过为每条记录分配一个字段来指示其所属的客户，从而在视图中实现多租户。
通过在作为客户 ID 的每个键上添加一个因素来实现它。
不过，似乎因为我将使用视图，所以我真的想同时做这两个。在第 2 种情况下，我需要在记录中包含数据，以便可以对其进行索引（或者我可以在映射阶段提取部分键并在客户上建立索引），并且在选项 1 中，我想要它是检索数据时检查的关键部分，以确保我不会发送错误的客户数据。
问题是，这是一项服务，多个客户将进行交互，有时一个客户会创建一些数据，而另一个客户会在第一个客户请求时查看它。但是，在每条记录上放置一个 ACL，列出所有有权查看它的人，至少可以说是有问题的。
我敢打赌，有一种通用的方法或设计模式可以回答这个问题，并且希望能得到一些最佳实践的指导。
如果索引同时对特定的相关数据和客户 ID 进行索引，我还担心性能......大量不同的客户可能会使索引效率低得多。（但也许不是。）
以下是我对您的问题的看法：
[关于项目 #1 和 2] - 不过，似乎因为我将使用视图，所以我真的想同时做这两个。
这对我来说似乎没有意义。在 Couchbase 中，映射阶段可以包含来自键和值的内容。将数据存储在键和值中几乎没有意义，因为您可以保证在那里有 1:1 的重复。将其存放在最适合存放它的地方；在这种情况下，可能是值。
问题是，这是一项服务，多个客户将进行交互，有时一个客户会创建一些数据，而另一个客户会在第一个客户请求时查看它。但是，在每条记录上放置一个 ACL，列出所有有权查看它的人，至少可以说是有问题的。
我的站点还具有存储在单个数据库中的多租户数据。在我的例子中，我使用对象唯一标识符作为我的键。默认情况下，客户可以访问属于他们的所有对象（我有一个用户对象，并且用户与客户帐户相关联）。用户还可以分配给他们额外的权限，从而可以将来自另一个客户的单个对象添加到他们的用户帐户中，从而授予他们查看对象的访问权限。
另一种选择是“通过默默无闻的安全性”并使用 guid 作为随机标识符，让客户可以访问查看他们拥有 guid 的任何对象。
但是，我不会尝试将权限存储在对象本身上。那很快就会变得笨拙。您需要考虑您的特定用例，并决定哪种简单方法适用于大多数情况，而不支持其他 1-2% 的情况。