生产中的数据库模式更新

eik*_*ooc 10 database database-migration firebase firebase-realtime-database

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

|-- "app"
|    |-- "a"
|         |--"y"
|    |-- "b"
|         |--"y"
Run Code Online (Sandbox Code Playgroud)

下列其中一个b合并为一个:

|-- "app"
|    |-- "x"
|         |--"y"
Run Code Online (Sandbox Code Playgroud)

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

问题是保持两个架构的一致性和更新,同时部署新的应用程序版本,因为我们不能确定人们已经更新了应用程序.

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

Kam*_*len 6

如果要保留旧版本和新版本的功能,唯一的选择是支持两个版本:

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

  • 如果某些结构已针对所有用户使用的全局数据进行了更改,则您的数据库应保留旧格式和新格式的数据.作为NoSQL,这应该只会导致写入一致性问题(需要更新所有位置).

是否支持Firebase,您不能期望永久支持旧版本的应用.如果您决定支持最新的X版本,则需要并行保留数据结构的X版本(以及写入操作中所有增加的复杂性).


Dir*_*nry 6

另一个有利有弊的解决方案:

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

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

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