如何最安全有效地处理不同数据库版本/文档结构之间的数据迁移?

How to most securely and effectively handle the data migration between different database versions / document structures?

前提 1:由于新功能、更新等,您的文档结构会随着时间的推移而改变。
前提 2:并非所有用户文档最终都会出现在您的服务器上,因为同步是一项额外费用特征。
前提 3:Web 或移动客户端期望数据以某种结构来自数据库以正常运行。

--> 我需要在客户端处理数据迁移。
--> 我需要跟踪曾经存在的所有数据库版本/文档结构,并确保我将它们安全地迁移到当前版本,否则数据会损坏并且应用程序无法再使用。
--> 如果出现问题,没有简单的方法可以解决,因为数据在客户端,我无法从服务器端解决。

解决方案 1:我将数据库的版本存储在文档中,并创建了一个 'migrateDB' 函数,用于在启动期间检查数据库版本并在需要时迁移所有文档。
--> 在随后的数据库读取过程中需要较少冗长的代码,因为客户端可以期望数据以正确的结构安全地迁移
--> 如果在迁移过程中出现问题,应用程序基本上不能再使用了

解决方案 2:客户端通过在每次读取时检查结构并在结构不符合预期时更新它们来按需迁移文档。
--> 这需要非常冗长的代码来从数据库中读取文档。它必须处理所有可能的结构,数据仍然可以存储在数据库中。
--> 你最终会得到一个数据库,其中一些文档仍然具有旧结构(因为它们尚未被读取),而其他文档已经被迁移

方案三:方案一+方案二

解决方案 4: ?

你是怎么处理的?

如果您发现在无模式文档存储上需要这种级别的数据迁移,则您可能没有以最佳方式使用它。

每个 consumer/client 都应在其逻辑中对其最低要求进行编码,并且应忽略任何其他字段。

因此,例如,如果客户端需要字段“name”、“part-id”和“count”,如果其中任何一个不存在,它应该会出错,但如果后续的新功能添加,它会正常运行文档的新数据字段。

在无模式数据库中,灵活性的代价是“模式验证”现在全部在客户端,在代码中,而不是模式中的完整性保证。

解决方案 4:期待并接受这样一个事实,即您的数据库将随着时间的推移包含不同的文档版本,并编写您的代码以尽可能宽容地应对这种情况。如果实在受不了,就批量迁移到数据源头的统一结构

提示——如果您要问 PouchDB 问题,还可以用 CouchDB 和 Cloudant 标记您的问题以获得最大的关注度。