いくつかの調査を行った後、人々が CouchDB でのスキーマの移行について尋ねると、その概念は NoSQL イデオロギーと完全に互換性がないとすぐに反論されるようです。NoSQL がスキーマレスであることを意図していることを理解していますが、直感に反しているように感じます。とはいえ、スキーマの移行を完全に回避する方法がわからない状況にいます。モバイル デバイスで NoSQL を使用しています。これが私のセットアップと私のニーズの大枠です。
- 各モバイル デバイスには、複製された独自のデータベースがあります。
- モバイル デバイスはオフラインで作業できます。
- モバイル デバイスは、クラウド サーバー上のデータベースを複製してデータを共有します。
- 可能な場合はデータが複製されるため、異なるデバイスの複数のユーザーが同じデータで作業できます。
- クライアントの新しいバージョンは、特定のキーに対して保存する値の型を変更することを決定できます (つまり、スキーマの変更に相当します)。
- ユーザーは、更新が利用可能になってもすぐにアプリを更新しない可能性があります。
- 更新されていないユーザーは、更新されたユーザーと同じデータで引き続き作業できる必要があります。
編集：
- アプリケーションは 100% ネイティブ コードです。
ここでの問題は、ソフトウェアの古いバージョンであるクライアントを使用しているユーザーが、新しいデータが int 自体ではなく文字列であることを期待しないことです。したがって、ユーザーにアプリの更新を強制したくないため、常にクライアント側で処理できるとは限りません。
別の角度から説明すると、何が起こるかというと、2 つの異なるクライアント バージョンを持つ 2 人のユーザーが同じデータを共有および変更できるようにしたいということです。つまり、後方互換性と前方互換性が必要です。後方互換性はしばしば取り組まれますが、前方互換性はもう少し問題があります。新しいスキーマを完全に解釈できないバージョンを使用しながら、最後に変更されたヒューリスティックを引き続き競合解決に使用する方法が必要です。
少し考えた後、クラウド データベースを複数のソースに分割するアプローチを検討することができました。すべてのモバイル デバイスがその変更をプッシュするデータベースと、モバイル デバイスがそのバージョンに適合した最新のデータをプルする one-to-x データベースです。それらの間のどこかで、スキーマの移行との後方互換性と前方互換性を処理する必要があります。
そのような設定であっても、スキーマの移行を回避する方法はありますか? 他のよりシンプルまたは安全なソリューションを見た人はいますか? このようなシステムの制限は何ですか? 私はここで自分が正しい軌道に乗っているとは感じていません。
ありがとう、ポール