web-dev-qa-db-ja.com

データベースの下位互換性のベストプラクティス

複数のバージョンが市場に展開されているアプリに取り組んでいます。異なるバージョンではデータベースが変更されており、データベースは署名されたユーザーによってローカルストレージとサーバーストレージ間で同期されます。問題は、ユーザーがさまざまなバージョンのアプリをさまざまなデバイスにインストールしていて、データベースの同期を維持したい場合があることです。データベースのバージョンが異なるため(スキーマが異なる、つまり列やデータ型が変更されている)、同じアカウントで同期するのは困難です。この種の問題を解決するためのよく知られたパターンはあるのでしょうか。これは非常に一般的な問題であり、より適切な対処方法が必要だと思います。

これまでのところ、1つのdbバージョンに準拠したデータ(サーバーから受信)を別のdbバージョンに準拠したデータ(ローカルストレージに保存)に変換するラッパーを作成することを考えています。

編集: @RobertHarveysコメントへの応答として、各データベースのバージョンが異なるスキームを持っていると仮定しましょう。たとえば、新しい列が1つのバージョンで追加され、古い列が新しいバージョンで削除される場合があります。さらに、データ型は他のバージョンで変更できます。

2

現在のシナリオ:

DEVICE1

  • col1
  • col2
  • col3

DEVICE2

  • col1
  • col2
  • col4
  • col5

DEVICE

  • col1
  • col3
  • col5

そして、各デバイスは「サーバー」に接続されています。つまり、あなたの側にデータのコピーがあります。

同期中:

意味のある方法で同期するには、サーバーコンポーネントにすべての列のスーパーセットが必要です。

[〜#〜]サーバー[〜#〜]

  • col1

  • col2

  • col3

  • col4

  • col5

各デバイスは、サーバーの状態の現在の表現を照会し、それに応じて列を更新します(たとえば、Device2は1、2、4、5を選択します)。

これでうまくいくはずです。


コメントセクションから質問に回答するための編集

(列の)データ型が1つのバージョンで変更された場合はどうなりますか?

datatype is changedの意味によって異なりますか?たとえば、V1StringDOBを選択していて、他のすべてのバージョンではTimestampがあるため、問題はないはずです。更新を処理する必要があります。マーシャリングされたフォームとアンマーシャリングのプロセスでは、必要な変換(DBへの文字列の書き込みまたは文字列のTimestampへの変換)を実行する必要があります。

一般的に:サーバーには1つの標準形式(「真実」)があり、各アプリケーションはニーズに合わせて転置する必要があります。

また、列の名前をどのように処理しますか(たとえば、Person(name、age、dob))? Person( 'name_v1、age_v1、dob_v1')、Person( 'name_v2、height_v2、age_v2、dob_v2')などのような名前を付けるべきだと思いますか?

上記の説明から明らかなはずです。異なるcolumn_versionsに特別な名前を付ける必要はありません。問題:ある長さの制限がある場合:最も短いものが優先されます。


これまで読んだことから、これは一時的な解決策としてのみ見て、新しいバージョンのアプリケーションにアップグレードするように人々に動機を与えることを強くお勧めします(お金、機能、お金と機能など)。あなたとあなたの顧客は頭痛が少なくなります。

1
Thomas Junk

そのような場合、アプリのバージョンでユーザーを追跡する必要があります。データベーススキーマに変更を加える場合は、以前のバージョンを使用しているユーザーがいる場合は、列名を削除しないでください。そのバージョンを使用しているユーザーがいない場合にのみ実行できます。

複数のアプリバージョンを管理するには、APIについてさらに作業する必要があります。 APIレベルでバージョン番号を使用することにより、このようなケースを処理できます。

APIの使用中に、APIでバージョン番号を送信し、バージョンの変更に応じて応答を提供/取得します。

3

アプリケーションは、下位互換性のために最初から計画する必要があります。そのため、新しいバージョンでは古い機能が削除されません(またはDBスキーマの列が削除されません)。このようにして、新しいバージョンが常に古いDBで動作することを保証します。

ただし、特定のデータのみを同期する必要がある場合は、バージョンの内部を大幅に変更せずにバージョン間の独立性と柔軟性を維持することなく、すべてのバージョンに同期アダプターを追加して、バージョン間のデータ交換を統一できます。

3
Omar

独自のバージョン番号付けの3つのレベルを使用します。

  1. フロントエンドコードバージョン(ハードコード)
  2. APIバージョン(ハードコード)
  3. データベースのバージョン(db定数に格納)

それらがすべて同じバージョンでない場合は、逸脱したレベルを強制的に更新してください。チェックおよび更新ルーチンは、起動時にトリガーされます。

1
sibert