生产中的数据库架构更新 [英] Database schema update in production

问题描述

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

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

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

  |- app 
 | |- x 
 | |- y 
  

同时在尚未升级到新客户端的两个客户端上均保持应用程序正常运行

问题是要保持两个架构的一致性和更新性，同时还要部署新的应用程序版本，因为我们不能保证人们已经更新了该应用程序。

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

解决方案

另一种有利于解决方案的解决方案缺点：

1. 让数据库存储应用程序的哪些版本与当前架构兼容


2. 启动应用程序时，首先要在数据库中查询此信息


3. 如果用户A具有兼容版本，请恭喜！


4. 如果用户B具有不是兼容版本，请邀请他更新他的应用，这可能会吸引他：
   
   
   
   
   • 也许他由于技术原因无法更新应用（例如，对于iOS应用程序，您已将部署目标增加到与该用户设备不兼容的iOS版本）
   
   
   • 也许他暂时无法更新应用程序，因为他的网络接收能力很差，等等。
   
   

我想维护Firebase上的DB有点过分，特别是如果您的应用有点社交性并且所有版本都应该可以正常运行时。如果1.0版创建的内容可供2.0版和3.0版访问，并且您对所有其他版本的组合重复使用此约束，那么维护起来会很麻烦。

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

I have an app installed on mobile phones where users read and write to a Firebase database. I want to do a database schema change from:

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

to the following where ​a​ and ​b​ were merged into one:

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

While keeping the app functioning on both clients that have not upgraded to the new version with the new schema structure and clients that have upgraded.

The problem is keeping the two schema consistent and updated, while deploying the new app version as we cannot be sure people have updated the app.

In Firebase is this possible as there is no server to handle that? As in does Firebase have any functionality to listen to write events and then duplicating that data to other places, or what are my options?

解决方案

Another solution with pros & cons:

1. Let your database store what versions of your app are compatible with the current schema
2. First thing when your app is launched, query this information in the DB
3. If user A has a compatible version, congrats!
4. If user B has not a compatible version, invite him to update his app, which could suck for him:
   • Maybe he's not able to update the app for technical reasons (for instance, for an iOS app, you increased your deployment target to an iOS version that is not compatible with this user's device)
   • Maybe he won't be able to update the app for a while because he's having poor network reception, etc.

I think maintaining several versions of the DB on Firebase is kind of an overkill, especially if your app is somewhat social and all versions should keep being functional. If version 1.0 creates content that should be accessible to version 2.0 and 3.0, and if you repeat this constraint to all other combinations of versions, uuugh, it's going to be a pain to maintain.

I think that's one major drawback using Mobile backend as a service solutions compared to traditional backends where maintaining a legacy endpoint would be much easier.

这篇关于生产中的数据库架构更新的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！