您认为，最好将firebase自动生成的随机ID用于新文档，或者如果我选择文档名称以便执行更简单的查询，这不是一个坏习惯吗？ 例如，我应该在我的文档中分配标题“ test @ gmail”，而不是在所有随机id文档的集合“ users”内部进行搜索，然后再搜索“ email = test@gmail.com”字段的用户。 .com”，然后在集合“用户”中搜索名称为“ test@gmail.com”的文档？ 你觉得呢？
答案 0 :(得分：0)
这很难回答，因为当我们不了解用例的概念时，您正在征求有关数据库结构的意见。
但是，让我抛出一些想法。
如果我选择文档的名称，以便可以更轻松地执行 查询
在查询进行过程中，键名无关，也与它包含的子数据没有任何关系。看看
users
-Y89j9kksd0kskd //a users uid for example
email: "thing@test.com"
-y9099k,msp,sps
email: "dude@thing.com"
如果要查询“ dude@thing.com”的电子邮件，查询将“忽略”每个子键（-Y89 ...- y90 ...等），并查看其中的email：节点。
如果您命名键并进行查询，则仍然没有区别，它仍然会忽略该键。它作为快照的关键属性返回，但这不是问题，因为我们知道值是电子邮件的电子邮件：child。
users
-thing@test.com
email: "thing@test.com"
-dude@thing.com
email: "dude@thing.com"
这里的问题是。不能在密钥名称中使用，因此现在您必须对每个密钥进行编码/解码。那是很多额外的代码。
更重要的是，如果电子邮件地址发生更改，您将必须更改所有数据中该电子邮件地址的每次出现。而且由于不能更改密钥，因此必须删除每个节点并重新编写。 gh。
使用第一个示例是可行的方法。您可以在整个应用程序中保留对该用户的引用（例如，使用uid），无论该节点内的子数据有什么变化（例如，电子邮件），其余数据都不会受到影响。
这里有一个，但是...总是有一个。
有时您可能想知道一条数据是否位于特定路径上-在这种情况下，您可以直接访问它。例如
users
-Y89j9kksd0kskd //a users uid for example
email: "thing@test.com"
things_i_like
food:
pizza: true
taco: true
color:
blue: true
wine:
ornellaia: true
假设我有-Y89j9kksd0kskd的用户uid，并且我想查看比萨饼是否是他们喜欢的食物。无需查询食物节点，我可以直接在以下位置访问它
/uid/things_i_like/food/pizza
并查看该值是否为真（或是否存在）
或者看看他们是否喜欢精美的意大利Ornellaia葡萄酒，在以下位置测试真假（或存在）
/uid/things_i_like/wine/ornellaia
如您所见，在顶层利用uid或Firebase创建的键不会影响您的查询，但是当您知道要访问已知节点内的特定数据点时，命名节点键是一种解决方案。 / p>
这完全是一种平衡，取决于您要运行哪种查询...如果您想了解所有喜欢披萨的用户，那将是一个查询（结构略有不同），因此您不知道具体路径和查询将是必需的。