生产中的数据库架构更新

Question

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

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

以下 a 和 b 合并为一个：

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

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

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

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

Answer 1

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

• 任何需要迁移的特定用户的数据结构都可以通过新的应用版本更新一次（检测旧格式是否仍然存在并写为新）。

• 如果所有用户使用的全局数据的某些结构已更改，则您的数据库应保留旧格式和新格式的数据。作为NoSQL，这应该只会导致写入一致性问题（需要更新所有位置）。

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

Answer 2

另一个有优点和解决方案的解决方案缺点：

1. 让您的数据库存储哪些版本的应用与当前架构兼容
2. 首次启动您的应用时，请在数据库中查询此信息
3. 如果用户A有兼容版本，恭喜！
4. 如果用户B没有兼容版本，请邀请他更新他的应用程序，这可能会让他感到厌烦：
   • 可能由于技术原因他无法更新应用程序（例如，对于iOS应用程序，您将部署目标增加到与此用户设备不兼容的iOS版本）< / LI>
   • 也许他无法更新应用程序一段时间，因为他的网络接收效果不佳等。

我认为在Firebase上维护几个版本的数据库有点过分，特别是如果你的应用程序有点社交，所有版本应该保持正常运行。如果版本1.0创建了版本2.0和3.0应该可以访问的内容，并且如果对所有其他版本组合重复此约束，那么，维护它将是一件痛苦的事情。

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