在做了一些研究后,似乎当人们在CouchDB中询问模式迁移时,他们很快就会反驳说这个概念与NoSQL意识形态不完全兼容.我理解NoSQL是如何构建模式的,并且感觉反直觉.然而,我处于这种情况,我不知道如何完全避免模式迁移.我在移动设备上使用NoSQL.这是我的设置和我的需求的重要部分.

>每个移动设备都有自己的复制数据库.
>移动设备可以脱机工作.
>移动设备与云服务器上的数据库复制以共享其数据.
>数据会尽可能复制,因此不同设备上的多个用户可以处理相同的数据.
>较新版本的客户端可以决定更改它为特定密钥存储的值类型(即等效的模式更改)
>如果有可用更新,用户可能无法立即更新应用程序.
>未更新的用户应该仍然可以处理与更新的用户相同的数据.

编辑：

>该应用程序是100％本机代码.

我的问题是,具有客户端的用户是该软件的旧版本,不会期望新数据是字符串而不是int本身.因此,由于我们不想强迫用户更新他们的应用程序,因此无法始终对客户端进行处理.

为了在另一个角度解释它发生的事情是我希望两个具有两个不同客户端版本的用户能够共享和修改相同的数据,这意味着我需要具有向后和向前兼容性.向后兼容性经常被解决,但前向兼容性有点问题.我需要一种方法来继续使用我最后修改的启发式来解决冲突,同时拥有一个无法完全解释新模式的版本.

经过一番思考,我可以考虑一种方法,我应该将云数据库分成多个来源;每个移动设备推送其修改的一个和一个到x的数据库,其中移动设备提取适合其版本的最新数据.在这些之间的某个地方,我应该处理与模式迁移的向后和向前兼容性.

有没有办法避免模式迁移,即使在这样的设置中？
有人看到任何其他更简单或更安全的解决方案吗？
这种系统有哪些局限性？
我不觉得我在这里正好走在正确的轨道上.

谢谢,
保罗

最佳答案 如果CouchApps是您的选择,那么您实际上可以规避不同客户端版本的问题.如果你不熟悉这些：CouchApps是基于
HTML CSS
JavaScript的应用程序,它们直接由CouchDB提供.在移动平台上,将它们嵌入Cordova(Phonegap)以访问本机功能可能会派上用场.

由于CouchApps基本上存储在CouchDB数据库中的设计文档中,因此可以像复制普通文档一样复制它们.这使您可以选择在客户端连接到服务器时执行客户端软件的更新(实际上它会在任何复制时自动发生).

如果您想考虑此选项,您可能需要查看garden20,Mobile Futon,kanso和erica.