2

物理的に異なる場所にいるユーザーのグループ向けの小さなアプリケーションを設計しています。アプリケーションは、クラウド内の中央データベースに接続します (つまり、中央サーバー上 - クラウドだと思いますが、実際にはクラウドではありません)。中央の場所でのバックアップを容易にするために、データベースは中央に保持されます。私はベテランの開発者であり、接続方法、コード、およびその他の要因は実際には問題ではありません。

ただし、ユーザーが適切だと判断したときに、アプリケーションを新しいバージョンにアップグレードできるようにする必要があります。スケジュールに関係なく。新しい更新では、データベース スキーマが変更される可能性があります。そこで、ユーザー A が新しいバージョンをダウンロードし、データベースをアップグレードするという問題に直面します。ユーザー B、C、および D がデータベースにアクセスしようとすると、テーブル/ビューが存在しない可能性があるため、エラーが発生します。

同じサーバー上で異なるデータベースを維持することを考えました。ユーザー A がアップグレードすると、データベースの値が DB_V1 から DB_V2 に「プッシュ」され、ユーザーはそれを使用します。ユーザー B、C、および D は、アップグレードを決定するまで DB_V1 を引き続き使用できます。最終的に、DB_V1 は、すべてのユーザーがそのデータベースからアップグレードしたときに削除できます。

クラウド風のアプリケーションでこれを処理する最善の方法について考えてもらえますか? クライアントが異なるバージョンを使用している可能性がある場合、DB の更新は通常どのように行われ、処理されますか?

4

1 に答える 1

0

残念ながら、それは難しく、特効薬はありません。ゲームの名前はバージョン管理であり、重複するバージョンをサポートする必要があります。アクセス API はバージョン管理されている必要があります。例えば。クライアントがRESTインターフェースを介して「クラウド」と通信することを検討してください。API のルート URL は、次のようになりhttp://example.com/api/v1.1/ます。新しいバージョンをデプロイすると、API も移動http://example.com/api/v1.2/され、この新しい API の新機能が公開されますが、古い v1.1 も引き続きサポートされます。クライアントが v1.2 にアップグレードする猶予期間を与え、十分な数のクライアントがアップグレードされた後、将来のある時点で v1.1 を廃止します。REST API 設計ハンドブックは、このトピックに関する優れたリソースです。

本当の問題はバックエンド、つまり URL サービスの背後にあるコードです。以前のバージョンとの下位互換性を維持するために、各アップグレード手順を慎重に設計する必要があります。重複する両方のバージョンが同じストレージ (同じ DB) を使用する可能性が非常に高いです。ユーザーが v1.2 API を使用してアイテムを追加した場合、v1.2 固有の属性がいくつか欠落している可能性はありますが、通常は後で v1.1 API を使用してそれを見つけることを期待しています。バックエンドは、v1.1 API を使用して追加/編集されたアイテムの v1.2 属性を処理する方法を決定する必要があります (例: デフォルト値、NULL など)。私が言ったように、それは難しく、特効薬はありません。場合によっては、やり過ぎて後方互換性を提供しないことが必要になる場合があります (v1.2 で追加された項目は、v1.1 API クライアントには表示されません。つまり、別のストレージ、別の DB を使用します)。

クライアントがDBに直接アクセスする場合はどうですか? すなわち。明示的な API はなく、クライアントはデータベースに直接接続します。成功の可能性が大幅に減少しました... DB とのやり取りに API を使用することができます。すべてにストアド プロシージャのみを使用します。スキーマを名前空間として使用することで、バージョン管理を提供できます。exec [v1.1].[getProducts]対exec [v1.2].[getProducts]。しかし、扱いにくく、難しく、エラーが発生しやすく、ほとんどの開発ツールのウィザード、オーム、その他のホイッスルやベルに別れを告げることができます。

于 2013-06-23T08:30:54.930 に答える