問題
データベースは、アプリケーションの不可欠な部分です。 バージョン1.0データベースに基づいてこのアプリケーションのバージョン2.0をデプロイすると、一般的な場合、結果は動作不能なプログラムになります。 そのため、データベースはプログラムのソースコードのすぐ横にあるバージョン管理システムに配置する必要があります。
問題の全体的なポイントは、データベースの場合に「直接」条件が満たされるのが非常に難しいという事実にあります。 問題は、バージョン管理システムに正確に何を保存するかです。 データベース全体？ 完全に無意味な活動。 スクリプト化されたデータベーススキーマ全体ですか？ 次に、既存の構造に増分変更を加える方法は？ 増分変更を伴うスクリプトですか？ もちろん、これが最も正しい決定になりますが、スクリプトが正しい順序で、必要な回数だけ、必要なデータベースに正確に適用されるようにする方法はどうでしょうか？
解決策
この時点で、特別な手段がシーンに入ります。
それらの1つ（すべてが開始された不cru慎なPRが始まります）-オクタルフォーティーWizardby。 このツールを使用すると、データベーススキーマを「条件に合わせる」ことを自動化して、必要なすべての操作を次の2つに減らすことができます。移行の記述と、前述の移行を処理するコンソールアプリケーションの操作。
実際、「移行」は、バージョンNのデータベーススキーマからバージョンN + 1スキームを作成する方法について説明する指示です。 他の（非常に異なる）言葉で：
migration "Oxite" revision => 1: <br> version 20090323103239:<br> add table oxite_Language:<br> add column LanguageID type => Guid, nullable => false , primary - key => true <br> add column LanguageName type => AnsiString, length => 8, nullable => false <br> add column LanguageDisplayName type => String, length => 50, nullable => false <br><br> * This source code was highlighted with Source Code Highlighter .
さらに：
最後に：
しかし、もしそうなら：
version 20090330170528:<br> oxite_User:<br> UserID type => PK, primary - key => true <br> Username type => LongName, unique => true <br> DisplayName type => LongName<br> Email type => LongName<br> HashedEmail type => ShortName<br> Password type => MediumName<br> PasswordSalt type => MediumName<br> DefaultLanguageID references => oxite_Language<br> Status type => Byte, nullable => false <br> <br> oxite_UserLanguage:<br> UserID references => oxite_User<br> LanguageID references => oxite_Language<br><br> index "" columns => [UserID, LanguageID], unique => true , clustered => true <br> <br> * This source code was highlighted with Source Code Highlighter .
とにかく、ウィザードビーは同じことをすべて行います。
プロジェクト
プロジェクトページ（MITライセンスの下でライセンスされています）はこちらです。 ソースコードは、 ZIPアーカイブまたはSVNリポジトリで入手できます 。 さらに、すでにコンパイルされたバージョンの ZIPアーカイブがあります。 ドキュメント（英語）はこちらです。 そして、 ここで Wizardbyが「実生活」でどのように使用されているかを見ることができます。