因此,我开始使用Firebase制作一个简单的待办事项列表应用程序,并且想知道Firestore是否将是一个不错的选择。我开始认为不是。
我希望这些任务可以重新排序,所以如果我(使用Firestore)具有一个包含任务集合的TaskList文档,我如何在不使它们变得太慢或混乱的情况下对其进行重新排序?
对于实时数据库,我认为每次重新排序任务时我都可以上载整个列表,因为这些都只是放在一个数组中。
此外,此应用可能会进行大量读写操作,因此Firestore可能会更昂贵。
我的想法合理吗,或者我在Firestore中缺少某些东西?谢谢!
答案 0 :(得分:0)
实时数据库的目的是使它更适合于对时间敏感的应用程序并在多个客户端之间同步数据。
排序,实际上只要您为文档创建索引就不会有太大问题。 这意味着服务器将能够根据日期索引有效地检索/插入新的待办事项。 https://firebase.google.com/docs/firestore/query-data/indexing
我不确定为什么ToDo应用程序会进行大量的读写操作,因此您可以基于有限的条件语句查询数据以减少数据传输。我不建议保存/上传整个待办事项列表,而是根据日期范围查询数据。
您还可以在本地缓存,从而进一步减少读/写 https://firebase.google.com/docs/firestore/manage-data/enable-offline
如果您曾经要求Notes在多个客户端之间实时同步(也许像google docs在线编辑),那么实时可能是一个更好的选择。
答案 1 :(得分:0)
请阅读official blog from when Firestore was released和official documentation that is comparing the two databases side by side以及answer by Todd Kerpelman here on StackOverflow。
- 实时数据库是Firebase的原始数据库。这是一个高效的 适用于需要跨状态同步的移动应用程序的低延迟解决方案 客户实时。
- Cloud Firestore 是Firebase的新旗舰 用于移动应用程序开发的数据库。它改善了成功 具有新的,更直观的数据模型的实时数据库。云 Firestore还具有更丰富,更快的查询,并且比 实时数据库。
关于任务项目的重新排序,您可以添加一个名为weight
或order
的字段,您可以在获取项目时对其进行排序。直接通过查询顺序或客户端中的本地排序。因此,可以通过将weight
更改为高于或低于另一个项目的数字来实现对项目的重新排序。
对于该参数,Firestore将是您更好的选择,因为它具有升序和降序排序,而实时数据库为always returns data in ascending order。
db.collection("lists").doc("the-list-id").collection("tasks").orderBy("weight", "desc")
db.collection("lists").doc("the-list-id").collection("tasks").orderBy("weight", "asc")
对于“大量读写”,您可能希望对您的情况进行更仔细的计算。对我个人而言,TODO列表听起来并不像一个特别高的读/写用例。这听起来很标准,所以仅凭这些信息,就不一定要针对Firestore。
但是,如果您收集一些使用情况数据,则可以根据the pricing中的公式轻松进行计数。也许您可以实现数据量的跟踪,使用Firebase Performance Monitoring进行读取/写入,以查看您的用户如何与您的数据进行交互(例如,为每个文档写入/读取一个计数器,以及为一个数据字节显示一个计数器)被读取/写入)。这将使您了解一个用户可能正在使用多少读写和带宽,并从那里获得估计的价格。
答案 2 :(得分:0)
我决定通过Firestore使用混合方法。我将列表信息存储在一个文档中,并存储对另一个具有一系列任务的文档的引用。这样,我可以只获取列表信息,而不需要所有任务。将任务存储在一个文档/数组中将使排序更加容易,并限制了更改订单后必须重写的文档数量。缺点是我的任务列表不能超过1MB,这不是一个严重的问题,我将必须执行两个查询才能完全获取列表信息和任务。