ソフトウェア製品の開発というすでに困難なプロセスでは、時々非常に不快な質問が発生します。それらの1つは、データベース構造の処理方法、バージョン情報の保存方法、サーバー上のデータベースコピーの更新方法、およびコラボレーションの整理方法です。

問題

データベースは、アプリケーションの不可欠な部分です。バージョン1.0データベースに基づいてこのアプリケーションのバージョン2.0をデプロイすると、一般的な場合、結果は動作不能なプログラムになります。そのため、データベースはプログラムのソースコードのすぐ横にあるバージョン管理システムに配置する必要があります。

問題の全体的なポイントは、データベースの場合に「直接」条件が満たされるのが非常に難しいという事実にあります。問題は、バージョン管理システムに正確に何を保存するかです。データベース全体？完全に無意味な活動。スクリプト化されたデータベーススキーマ全体ですか？次に、既存の構造に増分変更を加える方法は？増分変更を伴うスクリプトですか？もちろん、これが最も正しい決定になりますが、スクリプトが正しい順序で、必要な回数だけ、必要なデータベースに正確に適用されるようにする方法はどうでしょうか？

解決策

この時点で、特別な手段がシーンに入ります。

それらの1つ（すべてが開始された不cru慎なPRが始まります）-オクタルフォーティーWizardby。このツールを使用すると、データベーススキーマを「条件に合わせる」ことを自動化して、必要なすべての操作を次の2つに減らすことができます。移行の記述と、前述の移行を処理するコンソールアプリケーションの操作。

実際、「移行」は、バージョンNのデータベーススキーマからバージョンN + 1スキームを作成する方法について説明する指示です。他の（非常に異なる）言葉で：

migration "Oxite" revision => 1: version 20090323103239: add table oxite_Language: add column LanguageID type => Guid, nullable => false , primary - key => true add column LanguageName type => AnsiString, length => 8, nullable => false add column LanguageDisplayName type => String, length => 50, nullable => false * This source code was highlighted with Source Code Highlighter .

さらに：

最後に：

しかし、もしそうなら：

version 20090330170528: oxite_User: UserID type => PK, primary - key => true Username type => LongName, unique => true DisplayName type => LongName Email type => LongName HashedEmail type => ShortName Password type => MediumName PasswordSalt type => MediumName DefaultLanguageID references => oxite_Language Status type => Byte, nullable => false oxite_UserLanguage: UserID references => oxite_User LanguageID references => oxite_Language index "" columns => [UserID, LanguageID], unique => true , clustered => true * This source code was highlighted with Source Code Highlighter .

とにかく、ウィザードビーは同じことをすべて行います。

プロジェクト

プロジェクトページ（MITライセンスの下でライセンスされています）はこちらです。ソースコードは、 ZIPアーカイブまたはSVNリポジトリで入手できます。さらに、すでにコンパイルされたバージョンの ZIPアーカイブがあります。ドキュメント（英語）はこちらです。そして、ここで Wizardbyが「実生活」でどのように使用されているかを見ることができます。

.NETのデータベース移行

問題

解決策

プロジェクト

More articles: