更改firebase数据模型（多个应用程序版本正在生产中）

当您的iOS应用程序有多个版本正在生产时，更改Firebase数据模型的最佳方法是什么

由于中间没有“应用服务器”层，数据库模型中的任何更改都可能破坏旧版本的应用程序。 与性能相关的问题示例：

在1.0版中，我天真地将与帖子相关的所有内容都保存在“/posts/”下。现在在2.0版中，我想采纳Firebase的建议，添加一个“/user post”端点，以快速列出给定用户的所有帖子

使用iOS应用程序1.0版的用户不会向“/user posts”写入任何数据，因为该端点以前不存在。因此，使用版本2.0的用户不会看到使用旧版本应用程序的用户创建的任何帖子

理论上，我可以在某处创建一个服务器，监听“/post/”上的更改，并将它们添加到“/user posts”中。不过，如果你有很多不同版本的应用程序，这似乎很难长期保持

问题的新功能示例：

假设在你的移动应用程序1.0版中，你在“/posts/”上写新的博客文章。现在，在应用程序的2.0版中，您引入了一个团队功能，所有帖子都必须位于“/team/team id/posts”中

尚未升级到2.0版的用户仍将向“/posts”写信。使用2.0版的用户在阅读“/team/team id/posts”时，将看不到这些帖子

我知道您可以同时保留两个端点（以及基于团队ID的索引/帖子），但随着时间的推移，这似乎很难维护

传统解决方案：

如果我使用Django或Express之类的工具，我会进行数据库迁移，然后更新服务器端端点以创建blogpost

---

这将从客户端对数据库进行更改。理论上，我可以使用

Firebase

将应用服务器层添加到我的体系结构中，但这似乎不是建议的：

我建议您使用

Firebase远程配置

通过

UIAlertController

或其他屏幕（如果有更新可用）显示警报。您可以强制用户更新到当前版本，以后也不会有问题，因为无法创建使用旧代码的帖子

回答您的问题： 我会开发一个不同的应用程序，将其添加到同一个Firebase项目中，然后让这个应用程序将所有旧数据转换为新的数据模型。因此，您可以在发布新版本后执行此操作，旧的用户数据将转换为新的数据模型，并且一切工作都很顺利。对于每个对象，还可以有一个类似于

databaseVersion

的属性

---

为了防止将来出现问题，您可以在

Firebase实时数据库中设置名为
app version
的常规属性。每次发布之前，应用程序都会检查是否有更新的版本。如果没有，用户可以添加帖子，但是如果有更新的版本，您可以通过
UIAlertController
显示消息/警报，尽管我无法评论如何迁移或处理对当前应用的更改。将来，应用逻辑常量和Firebase远程配置可能是减轻某些数据结构更改的一种方法。或者，如果可行的话，使用某种机制鼓励用户使用新版本。也许通过提供新功能…谢谢你的建议。我确实考虑过强制升级，但这似乎是一个糟糕的UX。我最终直接从FB执行所有读取，但通过服务器代理写入。当模式发生变化时，服务器会将帖子双重写入旧位置和新位置。我认为强制升级这样的内容并不是糟糕的用户体验，这在Android和iOS上似乎很常见。