gpt4 book ai didi

java - Firestore DB 模型、文档或子集合中的属性

转载 作者:行者123 更新时间:2023-12-02 11:03:53 25 4
gpt4 key购买 nike

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

如果我有多个管理员,他们可以在他们的名下每个客户(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);

但是,如果您想要实现与第一个选项相同的效果并使用如下所示的查询:

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

您需要知道您无法实现这一目标。这是不可能的,因为在这种情况下您需要创建一个 index并且您无法为每个 uid 手动创建索引。

还有一件事,我建议您使用uid而不是电子邮件地址作为文档 key 。

关于java - Firestore DB 模型、文档或子集合中的属性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51127386/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com