恢复数据库模型,文档或子集合中的属性



我在建模Firebase/Firestore时经常遇到这条分裂的道路,也许你可以阐明这一点。

如果我有多个管理员可以在他们的名字下每个客户(100 个(。管理员看不到其他管理员客户端(将它们视为单独的公司(。什么会更好?

1( 添加客户端根集合,并在它下添加一个 ID 为管理员电子邮件的文档,并在该文档下添加一个包含客户文档的子集合:

Firestore-root
|
--- Clients(collection)
|
--- Admin ID/Email(Collection)
|
----------Clients Info (documents)

2( 或添加客户根集合,其下有客户文档,但每个文档中的属性将是管理员电子邮件:

Firestore-root
|
--- Clients(collection)
|
--- Clients Info (documents)
|
--- AdminId: (email)

我发现第一个更容易查询,最重要的是,如果您想在测试/甚至生产期间在控制台中查看数据,则更具可读性。但我发现第二个是级别数较少。

解决这个问题的正确方法是什么? 谢谢

数据库结构没有正确的方法。适合您的数据库的解决方案是适合您的需求并使您的工作更轻松的解决方案。我对你的数据库模式的看法实际上与你真正想要实现的目标有关。

如果要查询数据库以仅获取与特定管理员对应的客户端,则可以继续使用第一个选项。如果您希望在某个时候从数据库中获取所有客户端,那么第二个选项将帮助您实现此目的。因此,同时使用这两个选项可能是一种选择。

但是,如果要使用第二个选项实现相同的操作,则仅当使用基于单个属性(uid属性(的查询时,才有可能

,如下所示:
FirebaseFirestore rootRef = FirebaseFirestore.getInstance();
CollectionReference clientsRef = rootRef.collection("Clients");
Query query = clientsRef.whereEqualTo("uid", uid);

但是,如果您希望insend实现与第一个选项相同的目标,并使用如下所示的查询:

Query query = clientsRef.whereEqualTo("uid", uid).orderBy("aProperty", Query.Direction.ASCENDING);

你需要知道你无法做到这一点。这是不可能的,因为在这种情况下,您需要创建一个索引,并且无法为每个uid手动创建索引。

还有一件事,我建议您使用uid而不是email address作为文档键。

最新更新