cbd*_*per 0 firebase google-cloud-firestore
我目前正在决定我的Firestore数据结构。
我需要一个products集合,这些products项目将作为文档存在于其中。
这是我产品的领域:
题
我应该使用Firestore自动生成的ID 作为文档的ID ID,还是最好使用我uniqueKey(在很多情况下会查询到)作为文档ID?两者之间有最佳选择吗?
我想象如果我使用my uniqueKey,这将使我在检索单个文档时的工作更加轻松,但是在许多情况下,我也将不得不查询一种以上的产品。
使用我的uniqueKeyas ID:
db.collection("products").doc("myUniqueKey").get();
Run Code Online (Sandbox Code Playgroud)
使用我的Firestore自动生成ID:
db.collection("products").where("uniqueKey", "==", "myUniqueKey").get();
Run Code Online (Sandbox Code Playgroud)
这是我uniqueKey而不是自动生成的一个足够的理由吗?这里有经验法则吗?在这种情况下,最佳做法是什么?
In terms of making queries from a client, using only the information you've given in the question, I don't see that there's much practical difference between a document get using its known ID, or a query on a field that is also unique. Either way, an index is used on the server side, and it costs exactly 1 document read. The document get() might be marginally faster, but it's not worthwhile to optimize like this (in my opinion).
When making decision about data modeling like this, it's more important to think about things like system behavior under load and security rules.
If you're reading and writing a lot of documents whose IDs have a sequential property, you could run into hotspotting on those writes. So, if you want to use your own ID, and you expect to be reading and writing them in that sequence under heavy load, you could have a problem. If you don't anticipate this to be the situation, then it likely doesn't matter too much whose ID you use.
If you are going to use security rules to limit access to documents, and you use the contents of other documents to help with that, you'll need to be able to uniquely identify those documents in your rule. You can't perform a query against a collection in rules, so you might need meaningful IDs that will give direct access when used by rules. If your own IDs can be used easily this way in security rules, that might be more convenient overall. If you're force to used Firestore's generated IDs, it might become inconvenient, difficult, or expensive to try to maintain a relationship between your IDs and Firestore's IDs.
无论如何,您所做的决定不仅是从一般意义上讲哪个ID“更好”,而且还要考虑到在负载下考虑安全的情况下哪种ID更适合您的特定预期情况。
| 归档时间: |
|
| 查看次数: |
585 次 |
| 最近记录: |