【问题标题】:Save pushed id in Firebase Model在 Firebase 模型中保存推送的 id
【发布时间】:2018-01-10 09:56:33
【问题描述】:

我在这里有 2 个 firebase 问题:

A/ 在解析值时以编程方式将 ID 复制到本地模型(从数据库中排除)是一种好习惯吗?

B/ 另一种解决方案是:

  • 生成新密钥
  • 使用该密钥并将其复制到模型中
  • 将模型(和密钥)保存到数据库
val newPostRef = ref.child("posts").push() val key = newPostRef.key newPostRef.setValue(Post(key, "title", "content"))

这样,post id 将由数据库模型保存并使用 getValue(Post::class) 自动解析。

我觉得这不是一个好的解决方案,但请告诉我原因:)

问候

【问题讨论】:

    标签: android firebase firebase-realtime-database


    【解决方案1】:

    两种解决方案都保证数据一致性,但在数据库大小方面,解决方案 A 优于解决方案 B。

    通过使用解决方案 B,您的数据库结构将如下所示:

    "posts":{
        "nTY5U5NJJbPTJaPksPRNqau15H53" : {
          "message" : "Hello World",
          "sender" : "Rosário Pereira Fernandes",
          "key" : "nTY5U5NJJbPTJaPksPRNqau15H53"
        }
    }
    

    这应该使用大约 180 字节 的磁盘空间。请注意,此密钥在您的节点上重复了两次。为什么不删除它以节省空间?

    使用解决方案 B,您将拥有一个更小的数据库:

    "posts":{
        "nTY5U5NJJbPTJaPksPRNqau15H53" : {
          "message" : "Hello World",
          "sender" : "Rosário Pereira Fernandes"
        }
    }
    

    这将使用大约 135 个字节。这比解决方案 B 少 45 个字节。现在想象一下,如果您的数据库中有 1000 个帖子。您将在解决方案 B 上多使用 45000 字节。这足以存储大约 300 多个帖子,但它被额外的 key 属性占用了。

    不要忘记用于 GB 存储和 GB 下载的 Firebase Database has some price limitations。使用解决方案 B 会比使用解决方案 A 更快地达到此限制。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2014-08-12
      • 1970-01-01
      • 2011-12-18
      • 2016-07-31
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多