プログラムにパッチを当てたときにクライアントデータベースを更新するために使用しているのは何ですか？デスクトップアプリケーション用データベースの更新（パッチ適用）
はのは、このシナリオを見てみましょう：
どのようにこのプロセスを行っているのだろうか。私はいくつかの概念を持っていますが、経験豊富な人が私により良い解決策やアドバイスを与えることができると思います。したがってにはさまざまな側面がいくつかあります
移行フレームワークが必要です。
FluentMigrator
Entity Frameworkのコードファーストは、独自の移行フレームワークを取得しますが、それはまだベータ版だような既存のOSSのライブラリがあります。
あなたが明示的に提供したり、あなたのコードのDBのアップグレードメカニズムに隠された、とする必要があります。 最初はバージョン管理です。あなたはプログラムのバージョンにteeh dbのバージョンを結びつける何らかの方法が必要です。バージョン番号を持つテーブルのような単純なものかもしれません。アプリケーションの実行時にもチェックする必要があります。
アプリケーションとdbが正常に更新されていて、何らかの操作上の理由から、以前のバージョンのデータベースがリストアされている場合、または頻繁なパッチ・サイクルにいる場合は、各パッチを実行する必要があります順番に、または追いつくことができます。アプリケーションのみまたはデータベースのみのアップグレードを別々に扱いたいですか？
これには正しい方法はありません。間違っている可能性のあるすべてのものに対処するために、どのような変更を加え、維持するためにどのレベルの複雑性を備えているかを調べる必要があります。
見る価値があるカップル 静的な「読み取り専用」データ用と動的なもの用の2つのデータベース。静的データのアップグレードは、単にアップグレードパッケージ内のリソースからのリストアとすることができます。
もう1つは、DBテーブルに格納されているメタデータでどれくらいできますか。たとえば、具体的なクラスの代わりにオブジェクトを記述するためのxsdに基づくバージョンです。これはあなたの読み取り専用dbにあります。今では、コードとアプリケーションをリストア、場合によっては変換して更新しました。
多くの方法があります。ちょうど覚えておいてください。 「ユーザー」は、あなたが思ったことのない何かを行うことによって、eejitのように見えるようにする方法を常に見つけます。
システムを複雑にするほど、上記の可能性が高くなります。
最後に、データのバージョン変換を短縮しないでください。データの整合性が失われた場合、それ以外のものは無駄になります。
DBのバージョンチェーンのようなものを実装する -