【问题标题】:Firebase instead of SQLiteFirebase 而不是 SQLite
【发布时间】:2017-09-28 12:34:14
【问题描述】:

我一直使用 SQLite 作为我的 android 应用程序的存储解决方案。我希望能够为我的一个应用程序添加同步功能,Firebase 看起来是一个很好的解决方案,但问题是我需要知道我是否要使用 Firebase 将数据与 SQLite 数据库同步,或者 Firebase 可以工作并完全取代 SQLite .我知道 Firebase 具有离线持久性,但是在离线时它可以保存与 SQLite 一样多的数据并且查询是否强大?

【问题讨论】:

  • 根据 Firebase 离线功能文档“默认情况下,缓存 10MB 的先前同步数据。”它声称具有智能同步功能。除非您期望数据存储高于 10MB,否则您不妨只使用 Firebase。请参阅文档here
  • 谢谢,我需要一个离线的第一个解决方案,并且预计会超过 10MB,所以 Firebase 可能不是解决方案 :(,Realm 移动平台看起来更像我想要的。

标签: android database sqlite firebase nosql


【解决方案1】:

显然,这取决于考虑选项的业务规则。所以不会有“正确”的答案。

至少我们的一名团队成员是按照这些思路进行思考的。这是我们的解决方案:

  1. 在 SQLite 本地处理所有事务数据,因为我们不需要跨设备进行事务。

  2. 使用 Firebase 同步其余部分。

(1) 确保我们不会滥用 Firebase 对其客户端的非持久离线可用性。

The docs Even with persistence enabled, transactions are not persisted across app restarts. So you cannot rely on transactions done offline being committed to your Firebase Realtime Database. To provide the best user experience, your app should show that a transaction has not been saved into your Firebase Realtime Database yet, or make sure your app remembers them manually and executes them again after an app restart.

(2) 确保我们使用 Firebase 的持久离线特性在连接(重新)建立后跨设备同步非事务性数据。

The docs, The Firebase Realtime Database client automatically keeps a queue of all write operations that are performed while your app is offline. When persistence is enabled, this queue is also persisted to disk so all of your writes are available when the user or operating system restarts the app. When the app regains connectivity, all of the operations are sent to the Firebase Realtime Database server.

通过这种方式,我们实现了我们使用中可接受的状态。

“它是否可以像 SQLite 那样容纳尽可能多的数据,并且查询功能是否强大?” no 和 no if strong 被翻译为“transaction 跨设备”,根据 Firebase 的定义是一个远程数据库。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-11-23
    • 1970-01-01
    • 2023-03-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多