生产中的数据库模式更新答案

【问题标题】：Database schema update in production生产中的数据库模式更新
【发布时间】：2016-09-19 00:44:45
【问题描述】：

我在手机上安装了一个应用程序，用户可以在其中读取和写入 Firebase 数据库。我想从以下位置更改数据库架构：

|-- "app"
|    |-- "a"
|         |--"y"
|    |-- "b"
|         |--"y"

到以下，其中a和b合并为一个：

|-- "app"
|    |-- "x"
|         |--"y"

同时保持应用在尚未升级到具有新架构结构的新版本的客户端和已升级的客户端上运行。

问题是在部署新应用版本时保持两个架构一致和更新，因为我们无法确定人们是否更新了应用。

在 Firebase 中这是否可能，因为没有服务器来处理它？ Firebase 是否有任何功能来监听写入事件，然后将该数据复制到其他地方，或者我有什么选择？

【问题讨论】：

【解决方案1】：

如果您想同时保留新旧版本的功能，您唯一的选择是同时支持这两个版本：

无论是否使用 Firebase，都不能期望您永远支持旧版本的应用。如果您决定支持最多 X 个以前的版本，则需要保持 X 个版本的数据结构并行（以及写入操作中增加的所有复杂性）。

【讨论】：

【解决方案2】：

另一种有利有弊的解决方案：

让您的数据库存储与当前架构兼容的应用版本
启动应用后的第一件事是在数据库中查询此信息
如果用户 A 有兼容版本，恭喜！
如果用户 B 没有兼容的版本，请邀请他更新他的应用程序，这对他来说可能很糟糕：
- 可能由于技术原因他无法更新应用（例如，对于 iOS 应用，您将部署目标增加到与该用户设备不兼容的 iOS 版本）
- 可能因为网络接收不佳等原因，他暂时无法更新应用程序。

我认为在 Firebase 上维护多个版本的数据库有点过头了，尤其是当您的应用有点社交性并且所有版本都应该保持正常运行时。如果 1.0 版创建了 2.0 版和 3.0 版应该可以访问的内容，并且如果您对所有其他版本组合重复此限制，呃，维护起来会很痛苦。

我认为这是使用移动后端即服务解决方案的一个主要缺点，与传统后端相比，传统后端维护旧端点会容易得多。

【讨论】：