在Firestore中使用“集合组查询"的多租户应用最佳实践是什么? [英] What is the best practice for a multi-tenant app with Collection Group Queries in Firestore?

问题描述

多租户应用程序集合查询的最佳实践是什么?例如，查询租户客户的所有发票

What is the best practice for multi-tenant app collection group queries? For example query all invoices for a tenant's customers

/tenant/1/customer/2/invoices

如果我创建一个名为 invoices 的集合组索引，并且想要确保可以获取租户1的所有 invoices ，我该如何轻松地做到这一点?

If I create a collection group index called invoices, and I want to ensure that I can get all invoices for tenant 1, how do I do this easily?

我尝试设置一些安全规则以防止对租户进行查询，但是由于仍在跨租户查询，因此它仍然引发Access拒绝错误.正确的Firestore规则会是什么样子

I tried setting up some security rules to prevent from querying over the tenants but it still threw Access denied errors since it was still querying across tenants. What would the correct firestore rules look like

推荐答案

Firebase项目不太适合多租户应用程序.建议您为每个租户创建不同的项目.这将在将来为您节省很多问题.

Firebase projects are not very well suited to multi-tenant apps. It's recommended that you create different projects for each tenant. This will save you a lot of problems in the future.

如果您绝对必须在一个项目上具有多租户，则当前的数据库结构不能很好地支持集合组查询.集合组查询总是查询给定名称的每个集合，没有例外.您不能使用安全规则来过滤结果，因为规则不是过滤器.筛选只能来自客户端，并由安全规则确认.在当前结构下，您需要将租户ID存储在要使用集合组查询查询的每个文档中，并让客户端将其用作结果过滤器.

If you absolutely must have multi-tenancy on a single project, your current database structure does not support it very well for collection group queries. Collection group queries always query every collection of a given name, with no exceptions. You can't use security rules to filter the results, because rules are not filters. Filtering can only come from the client, and be confirmed by security rules. With your current structure, you would need to store the ID of the tenant in each document that you intend to query with a collection group query, and have the client use that as a filter for results.

这篇关于在Firestore中使用“集合组查询"的多租户应用最佳实践是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！