Firebase模型ID存储两种方案的合理性咨询

嘿，我来帮你拆解这两个Firebase的实践问题：

问题A：本地模型存储ID（不写入数据库）是否为最佳实践 #

这绝对是推荐的最佳实践，Frank的建议非常合理。原因很简单：

• Firebase Realtime Database/Firestore中，节点/文档的ID是存储在路径层级中的，并不属于数据本身的一部分。当你读取数据时，DataSnapshot（Realtime Database）或DocumentSnapshot（Firestore）本身就带有这个ID，但它不会被自动映射到你的本地模型里。
• 把ID存到本地模型里，是为了后续操作（比如更新、删除这条数据，或者在UI中关联对应的资源）方便调用，但完全没必要把它写回数据库——这会造成数据冗余，还可能引发后续的一致性问题（比如不小心修改了模型里的ID，但数据库节点ID没变）。
• 这种方案既保留了业务逻辑所需的标识信息，又不会污染数据库的数据结构，是Firebase开发中非常普遍的做法。

问题B：将生成的密钥存入模型再保存的问题所在 #

你的直觉是对的，这种方案确实存在不少弊端：

1. 数据冗余：push()生成的key已经是节点的唯一标识（路径中的ID），再把它存入节点的数据里，相当于重复存储了相同的信息，浪费数据库存储空间，尤其是数据量较大时，冗余成本会被放大。
2. 一致性风险：如果后续业务逻辑中不小心修改了模型里的key字段，并重新写入数据库，就会出现模型中的key与实际节点ID不匹配的情况——之后用模型里的key去操作数据库时，就会找不到对应的节点，引发错误。
3. 架构设计不合理：节点ID属于数据库的元数据，而非业务数据。把元数据混入业务模型中，违背了单一职责原则，业务模型应该只承载和业务相关的内容（比如标题、内容），ID这类标识信息应该从数据库的快照中获取并赋值给模型，而非写入数据库。
4. 不必要的解析复杂度：其实你完全可以在读取数据时，直接从DataSnapshot.key获取节点ID，再赋值给本地模型，这样既可靠又不会产生冗余，比把ID写进数据库再解析要更简洁。

举个更合理的读取示例：

ref.child("posts").addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val posts = mutableListOf<Post>()
        for (childSnapshot in snapshot.children) {
            val post = childSnapshot.getValue(Post::class.java)
            post?.id = childSnapshot.key // 直接从快照获取ID赋值给模型
            post?.let { posts.add(it) }
        }
        // 处理posts列表
    }

    override fun onCancelled(error: DatabaseError) {
        // 处理错误
    }
})

这样既避免了冗余，又保证了ID的一致性，是更规范的做法。

内容的提问来源于stack exchange，提问作者MalikDe