我目前正在确定Firestore数据结构。
我需要一个products集合，并且products项将作为文档存在于其中。
这是我的产品字段：
问题
我应该使用Firestore自动生成的ID作为文档的ID，还是最好使用uniqueKey（我会在很多情况下查询）作为文档ID ？两者之间有最佳选择吗？
我想像一下，如果我使用uniqueKey，则在检索单个文档时将使我的生活更轻松，但是在很多情况下，我也不得不查询一种以上的产品。
将我的uniqueKey用作ID：
db.collection("products").doc("myUniqueKey").get();
使用我的Firestore自动生成的ID：
db.collection("products").where("uniqueKey", "==", "myUniqueKey").get();
这足以成为我的uniqueKey而不是自动生成的一个理由吗？这里有经验法则吗？在这种情况下，最佳做法是什么？
答案 0 :(得分：7)
就从客户进行查询而言，仅使用您在问题中提供的信息，我看不出使用已知ID的文档与对字段的查询之间存在实际差异也很独特无论哪种方式，在服务器端都使用索引，并且它的读取成本仅为1个文档。文件get（）可能稍快一些，但是（我认为）进行这样的优化是不值得的。
在做出这样的数据建模决策时，考虑诸如负载和安全规则下的系统行为之类的事情更为重要。
如果您正在读取和编写许多ID具有顺序属性的文档，则可能会在这些写入时遇到hotspotting。因此，如果您要使用自己的ID，并且希望在高负载下按此顺序进行读取和写入，则可能会遇到问题。如果您不希望出现这种情况，那么使用谁的ID可能无关紧要。
如果您要使用安全规则来限制对文档的访问，并使用其他文档的内容来帮助实现此目的，则需要能够在规则中唯一标识那些文档。您无法对规则中的集合执行查询，因此您可能需要有意义的ID，这些ID在被规则使用时将提供直接访问。如果可以轻松地在安全规则中使用您自己的ID，那么从整体上来说可能更方便。如果您被迫使用Firestore生成的ID，尝试维护ID与Firestore的ID之间的关系可能会变得不便，困难或昂贵。
无论如何，您所做的决定不仅是从一般意义上讲哪个ID“更好”，而且还要考虑到在负载下您的特定预期情况，哪个ID更好（em） 。