英文:
What is the best way to structure a todo list database with Firestore to create a reference between projects and tasks?
问题
我目前正在使用Flutter构建一个待办事项应用程序。
目前我的结构如下:
users/{userid}/projects/{projectid}/tasks/(all the tasks) (1)
但我也想到了以下的想法。(2)
users/{userid}/projects/{projectid}
users/{userid}/tasks/{taskid} // 所有任务都引用projectid
从项目集合获取所有任务(1)或通过它们的projectid搜索所有任务(2)是否会对性能有影响?
如果你有更好的建议,请随时纠正我。如果可能的话,列出这两种方法的一些正面和负面方面。
英文:
I’m currently building a todo application with Flutter.
Currently my structure looks like this:
users/{userid}/projects/{projectid}/tasks/(all the tasks) (1)
But I've also come up with the following idea. (2)
users/{userid}/projects/{projectid}
users/{userid}/tasks/{taskid} // All tasks hold a reference to the projectid
Is there a difference in performance by getting all tasks from a project collection (1) or by searching all tasks by their projectid (2)?
Feel free to correct me if you come up with better ideas. Also list some positive/negative points about the two approaches if you can.
Here is the current structure (userid, todos, and all the todos).
答案1
得分: 0
基于我的观察:
-
你将一个项目的所有任务都存储在一个名为
project
的集合中。如果你希望一次性访问与项目相关的所有任务,这种结构可能会有帮助。然而,根据特定标准进行搜索或筛选可能会具有挑战性且耗时。 -
你独立地保留任务并引用它们的
project
。如果你希望根据特定标准搜索或筛选任务,这种结构可能会有帮助。但一次性检索一个项目的所有任务可能会具有挑战性且耗时。
因此,结构的选择可以根据你的用例
和要求
来考虑。
英文:
Based on my observation:
-
You store all of a project's tasks under a
project
collection. If you wish to access all the tasks associated with a project at once, this structure may be helpful. Yet, it could be challenging and time-consuming to do a search or filter job based on certain criteria. -
You are keeping tasks independently and referencing their
project
If you wish to search or filter tasks based on certain criteria, this structure may be helpful. But challenging and time-consuming to retrieve every job for a project at once.
So choice of the structure can be considered based on your usecase
and requirements
答案2
得分: 0
Firestore的读取和查询性能不取决于需要考虑的文档数量,而完全取决于需要返回的文档数量和大小。因此,在基于此的两种数据模型之间性能没有区别。
Firestore的主要限制在于写入性能,您将希望避免所谓的热点。热点发生在数据库需要迅速连续写入接近的数据时,例如,当您一遍又一遍地更新相同的文档,当您具有连续的文档ID,或者当您具有具有这种连续值的索引(例如当前时间戳)时。
文档中已经涵盖了很多内容,因此我建议查看Firestore最佳实践页面以及视频系列了解Cloud Firestore。
英文:
Firestore's read and query performance does not depends on the number of document it needs to consider, but instead solely depends on the number and size of the documents it has to return. So there is no difference in performance between the two data models based on that.
Firestore's main limitations are about write-performance, where you'll want to avoid so-called hotspots. Hotspots occur when the database has to write data that is close to each other on disk in rapid succession, e.g. when you're updating the same document over and over, when you have sequential document IDs, or when you have indexes that have such sequential values (such as when you have the current timestamp).
A lot of this is covered in the documentation, so I recommend checking out the page on best practices with Firestore and in the video series Get to know Cloud Firestore.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论