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

前提1：由于新功能、更新等，文档的结构会随着时间的推移而改变。前提2：并非所有用户文档都会出现在服务器上，因为同步是一项高级功能
前提3：web或移动客户端希望数据以某种结构来自数据库，以便正常运行

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

解决方案1：我将数据库版本存储在文档中，并创建一个“migrateDB”函数，该函数在启动期间检查数据库版本，并在需要时迁移所有文档
-->在后续的数据库读取过程中需要更少的详细代码，因为客户机可以期望数据安全地迁移并处于正确的结构中
-->如果在迁移过程中出现问题，该应用程序基本上无法再使用

解决方案2：客户机根据需要迁移文档，每次读取时检查结构，如果结构不符合预期，则进行更新
-->这需要非常详细的代码从数据库中读取文档。它必须处理每一种可能的结构——数据仍然可以存储在数据库中
-->您将得到一个数据库，其中一些文档仍然具有旧的结构（因为它们尚未被读取），而其他文档已经被迁移

解决方案3：解决方案1+解决方案2

解决方案4：

---

如何处理此问题？

如果您发现需要在无架构的文档存储上进行此级别的数据迁移，则可能没有以最佳方式使用它

每个消费者/客户机应在其逻辑中编码其最低要求，并应忽略任何附加字段

因此，例如，如果客户机需要字段“name”、“part id”和“count”，如果其中任何一个字段不存在，则会出错，但如果后续新功能向文档中添加新数据字段，则会正常工作

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

解决方案4：期望并接受这样一个事实：随着时间的推移，您的数据库将包含不同的文档版本，并通过尽可能的允许编写代码来应对这种情况。如果它变得难以忍受，那么在真相的源头进行批量作业迁移到统一的结构

提示——如果你在问PockDB问题，也可以用CouchDB和Cloudant标记你的问题，以获得最大的眼球