アプリケーションデータベースの変更を追跡するのは簡単なことではありません。 原則として、データベーススキーマは異なる環境では一致せず、1つのデータベースのデータにデータの重要な部分が含まれていない場合があります。 そのような状況は、特に本番環境で発生する場合、不快になる可能性があります。
あなたがソフトウェア開発者である場合、状況はさらに悪化します。 この場合、各クライアントには独自のデータベースインスタンスがあり、その構造は他のものとは異なる場合があります。 このようなプロジェクトでは、顧客データベースの変更を追跡するのは悪夢です。
データベースのバージョン管理の最良のアプローチを見てみましょう。
データベースのバージョン管理：問題
まだ実稼働環境でリリースされていないプロジェクトのみで作業する場合、データベースのバージョン管理の問題などの問題はありません。 希望する方法でデータスキームを変更すると、常に機能します。
プログラムが本番環境で作業を開始するか、新しいチームメンバーがプロジェクトの一部に関連するデータベースの作業に参加すると、問題が発生します。 複数のデータベースインスタンスがあるとすぐに、同期解除が開始されます。 単一のインスタンスであっても、複数の開発者がそのインスタンスを使用している場合、変更を同期するにはかなりの時間がかかります。
おなじみ？ あなたはそのような状況を何度も経験しているに違いない。 もちろん、私はそうでした。
データベースのバージョン管理への最良のアプローチ
幸いなことに、私たちは一人ではありません。 この主題について書かれた多くの資料があります。 この問題を解決できるソフトウェアも同様です。 トピックをさらに深く学習したい場合は、 この本をお勧めします。 これは、データベースを使用するコードと組み合わせてデータベースを開発する方法に関する包括的なガイドです。
さて、データベースのバージョン管理に関するこれらのベストプラクティスは何ですか？
ベストプラクティス＃1：アプリケーションデータベースと参照データを通常のコードとして扱う必要があります。 つまり、スキーマと参照データの両方をバージョン管理システムに保存する必要があります。
このルールには、データベーススキーマだけでなく、参照データも含まれることに注意してください。 参照データは、アプリケーションの実行に必要なデータです。 たとえば、アプリケーションが構築されているすべての可能なタイプのクライアントのディクショナリがある場合、バージョン管理システムに保存する必要があります。
ベストプラクティス＃2：データベーススキーマと参照データへのすべての変更を明示的に保存する必要があります。 つまり、変更ごとに、変更を含む個別のSQLスクリプトを作成する必要があります。 変更がスキーマと参照データの両方に影響する場合、それらは1つのシナリオに反映される必要があります。
このルールに従うことは、データベースバージョン管理システムを構築する上で重要な部分です。 多くのプロジェクトはデータベーススキーマをバージョン管理システムに保存しますが、多くの場合、これはデータベースの最新バージョンのスナップショットにすぎません。 その中のすべての変更はバージョン管理システム自体によって追跡され、明示的に保存されません。 さらに、参照データへのすべての変更は、多くの場合追跡されません。
Visual Studioなどのツールは、自動的に生成されたスクリプトを使用してデータベース設計のデータスキーマを更新することをプログラマに強調し、奨励しています。 これは小さなプロジェクトではうまくいくかもしれませんが、大きなプロジェクトでは、自動生成されたスクリプトを使用してデータベースへの変更を追跡するのは負担になります。 次の投稿では、Visual Studioのデータベースプロジェクトと他の利用可能なツールについて説明します。
ベストプラクティス＃3：各SQLスクリプトファイルは、運用環境または中間環境への展開後に変更しないでください。
変更を別々のファイルに保存することのポイントは、それぞれを制御（追跡）できることです。 既存のSQLスクリプトを変更すると、提供されたデータベースのバージョン管理のベストプラクティスを使用する利点がすべて失われます。 スクリプトファイルを展開した後も変更しないでください。 すでに行われた変更をロールバックする必要がある場合は、このために別のスクリプトを作成します。
ベストプラクティス＃4：データベース内のスキーマおよび参照データに対するすべての変更は、スクリプトを介して適用する必要があります。 それらはどれも手動で適用できません。
スクリプトをバイパスしてデータベースを変更すると、データベースをバージョン管理するという考え全体が役に立たなくなるため、作成するSQLスクリプトのみを使用して変更が行われるようにする必要があります。
ベストプラクティス＃5：チームの各開発者は、独自のデータベースインスタンスを持つ必要があります。
多くの場合、チームは開発環境の単一のデータベースから始めます。 これは最初はうまく機能しますが、データベースが十分に大きくなると、ある時点ですべてのユーザーが機能しなくなるまで、データベースの同時変更がますます難しくなります。
多くの場合、プログラマは互換性のない変更を行います。そのため、各プログラマがこのような衝突を回避するために個別のデータベースインスタンスを持つことをお勧めします。 開発者がデータベーススキーマの一部を同時に変更すると、C＃/ Javaなどの競合など、バージョン管理システムを使用してそのような競合を解決できます。
さらに、コードベースに複数のブランチがある場合、これらのブランチのデータベースの違いに応じて、それぞれに個別のデータベースインスタンスを作成することもできます。
ベストプラクティス＃6：データベースバージョンはデータベース自体に保存する必要があります。 原則として、「設定」という別のテーブルを作成し、そこにバージョンを保存します。 バージョン番号に「xyz」などの複雑な表記を使用せず、整数を使用してください。
このアプローチの利点は何ですか？
それでは、データベースのバージョン管理への最善のアプローチはどのような利点をもたらしますか？
最初の最も重要なプラスは、このアプローチを使用すると、データベーススキーマの不一致に関する問題が発生しなくなることです。 もちろん、上記の規則を完全に順守している場合、最新バージョンへの自動更新はそれらを完全に解決します。
これは、単一の本番データベースがなく、各クライアントに独自のデータベースインスタンスがある場合に特に役立ちます。 適切なバージョン管理手法を使用しないと、このような条件下でデータベースのバージョンを管理するのは大変です。
ベストプラクティスを使用するもう1つの利点は、データベースの変更の強力な一貫性です。 これは、スキームおよび参照データの各既知の変更が1か所に反映され、アプリケーション全体に散在しないことを意味します。
SQL更新スクリプトには、データベースに必要なすべての変更が含まれているという意味で、強力な接続性が備わっているため、特定の機能のロックを解除するためにデータベースに変更が加えられたことが容易に理解できます。 互いに関連するスキーマとデータの変更を1つのファイルに保存することも非常に役立ちます。
この投稿で説明されているアプローチは、最初から従わなかった場合でも適用できます。 これを実際に使用するには、現在運用環境にあるデータベーススキーマの初期スクリプトを作成するだけで、これから徐々に変更を開始できます。 現在のバージョンはバージョン1である必要があります。このバージョンでは、上記で説明したアプローチを使用して先に進むことができます。