Question

在为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)

我发现第一个更易于查询，最重要的是，如果要在测试/甚至生产期间在控制台中查看数据，则第一个更易于阅读。但是我发现第二个级别更少。

解决此问题的正确方法是什么？谢谢

Answer 1

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

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

但是，如果您想使用第二个选项实现相同的目的，则只有在您使用基于单个属性（uid属性）的查询时，才有可能这样做： / p>

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代替email address作为文档密钥。

Firestore数据库模型，文档或子集合中的属性

1 个答案: