同じアプリケーションの古いバージョンで共有されているデータベースへの破損したデータベースの変更の移行の管理

Question

私の目標の1つは、古いバージョンと並行して実行されるWebアプリケーションの新しいバージョンをデプロイできるようにすることです。問題は、すべてがデータベースを共有することです。新しいバージョンでは、データベーステーブルへの重要なリファクタリングを含む傾向があるデータベース。新しいバージョンのアプリケーションを時間をかけてユーザーに展開し、必要に応じて古いバージョンに戻すことができるようにしたいと思います。

Orenには投稿で問題を設定しましたが、次のように終わりました：

＆quot;システム全体に影響する変更に関して、つまりデータベースの変更を壊すために、本番環境への展開に関しては、やや濁っています。次回の記事では、これは少し手に負えないことを議論するつもりです、私は恐れています。＆quot;

次の投稿は来ませんでした;-)。同じアプリケーションの古いバージョンで共有されているデータベースへの、破損したデータベースの変更の移行をどのように管理しますか？データをどのように同期し続けますか？

Answer 1

古いバージョンを維持する必要がある場合、変更は単純に破壊されません。また、Webアプリの新しいバージョンを展開するときに役立ちます。ロールバックする必要がある場合、データベースをそのままにしておくことができれば本当に役立ちます。

明らかにこれには大きなアーキテクチャ上の障害があり、ほぼ間違いなくその系統を示すデータベースになりますが、私の経験では、展開の利点は通常頭痛の価値があります。

関連する古いバージョンごとに統合テストの強固なコレクションがある場合に役立ちます。 「おそらくライブ」と思われるすべてのバージョンについて、移行したテストデータベースに対してそれらを実行できる必要があります。 -「これまでのすべてのバージョン」である可能性があります。ある場合には。展開を合理的に厳密に制御できる場合は、3つまたは4つのバージョンとの互換性だけで済む可能性があります。その場合、実際のニーズがある場合は、古いテーブル/列などを段階的に廃止することを計画できます。このような計画の複雑さは、発生するメリットに反することに留意してください。

Answer 2

スコットアンブラーの本を読む＆quot; リファクタリングデータベース＆quot ;;ひとつまみの塩で取りますが、そこには良いアイデアがたくさんあります。

利用可能なソリューションの詳細は、使用するDBMSによって異なります。ただし、次のようなことができます。

• 新しいデザインの新しいテーブル（またはいくつかの新しいテーブル）を作成します
• 新しいテーブルからデータを収集する古いテーブル名でビューを作成します
• ビューの代わりに新しいテーブルを更新するためにビューの「代わりに」トリガーを作成します

状況によっては、新しいテーブルは必要ありません-トリガーが必要な場合があります。

Answer 3

クライアントのバージョンが2つしかない場合、新しいテーブルにデータのコピーを1つだけ保持します。

新しいテーブルの上にあるビューの背後にある古いアプリと新しいアプリの間の契約を維持できます。 「古い」への書き込みを処理するには、トリガーの代わりにbefore /代わりに使用します。実際に新しいテーブルに書き込むビュー。

2つのバージョンのコードを維持しており、古いアプリを引き続き開発する必要がありますが、避けられません。

この方法では、同期の問題はありません。実質的に「古い」と「古い」間のレプリケーションの競合に対処する必要があります。および「新規」スキーマ。

前述のように2つ以上のバージョンが複雑になります...

Answer 4

まず、この問題は非常に困難であり、完全な答えが見つからない可能性があると言いたいと思います。

最近、私はレガシの基幹業務アプリケーションの保守に携わっており、すぐに新しいバージョンに進化するかもしれません。メンテナンスには、バグの解決、古いコードの最適化、および現在のアプリケーションアーキテクチャに簡単に適合できないことがある新機能が含まれます。アプリケーションの主な問題は、文書化が不十分であり、変更の痕跡がなく、基本的にこのプロジェクトに取り組んでいる5番目のローテーションチームであることです（かなり新しい）。

外側の詳細（コード、レイヤーなど）を残して、データベースの変更を現在どのように管理しているかを少し説明しようとします。

現時点では、従おうとしている2つのルールがあります。

1. まず、古いコード（sql、ストアドプロシージャ、関数など）がそのまま機能し、ケース（バグまたは機能の変更）がない限り、あまり変更せずにそのままにしておく必要があります。もちろん、可能な限り文書化してください（特に次のような問題： ＆quot; WTF !、なぜ彼はそれの代わりにそれをしたのですか？＆quot;）。

2. 2つ目は、追加されるすべての新機能が現時点で知られているベストプラクティスを使用し、古いデータベース構造をできる限り変更しないことです。これにより、古い構造の上で編集可能なビューを使用する、既存のテーブルに新しい拡張テーブルを導入する、構造を正規化する、ビューを介して古い構造を提供するなどのデータベースリファクタリングオプションが導入されます。

また、ビジネスアナリストが並んで作業し、ビジネスルールを文書化している限り、できるだけ多くの単体テストを記述しようとしています。

データベースのリファクタリングは、短い答えで答えられる非常に複雑なフィールドです。すべての問題に答える本がたくさんあります。 1つのhttp://databaserefactoring.com/ が1つに示されています回答。

後の編集：2番目のルールが重大な変更の処理にも応答することを願っています。