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