SQL Server 2008 がインストールされた 2 つのサーバー マシン (1 つは開発用、もう 1 つはクライアント用) があります。開発者が開発サーバーのテーブル/ビュー/ストアド プロシージャに変更を加えるたびに、クライアント サーバーにも反映する必要があります。
現在、テーブルの新しい列、ストアド プロシージャの変更など、すべての変更を手動で処理しています。DB スクリプトまたはレプリケーションによって、手順全体を自動化できますか? または、データベース スキーマの一貫性を保つためのより良い解決策があります。
助けていただければ幸いです。
ありがとう！
すべてのスキーマ変更が SQL スクリプトのみで行われる環境を作成することを強くお勧めします。どの環境でも「手動」ではありません。各開発者は、自分のバグ修正 (または新機能) に関連するスクリプトをバージョン管理システムにコミットする必要があります。
通常、データベースを最初から作成する 1 つの大きなスクリプトと、各バージョンのアップグレード (1.0 から 1.1、1.1 から 1.2 など) ごとに 1 つの大きなスクリプトがあります。
人手があれば、バージョンごとに 1 つの「最初から」スクリプトを維持することも非常に便利です。それが必要かどうかは、空のシステムへのインストールが行われる頻度によって異なります。
Liquibase を使用してこれらすべてを維持することについて、私たちは非常に良い経験を持っています。データベースに適用されたパッチと、アップグレード中に実行する必要があるパッチを自動的に追跡します。また、同じ移行を 2 回実行することもできなくなります。
変更がテストされ、ソース管理に適切にチェックインされていることを確認した後、人間がデプロイを行うべきだと思います。これは完全に自動化するものではありません。
ただし、人間はツールを使用する必要があります。私は Visual Studio 2010 Professional を使用しています。Visual Studio 2010 Professional には強力なスキーマ比較ツールがあり、配置スクリプトを生成して実行し、ソース管理が統合されています。
すべてのデータベース アプリケーションが抱える問題であり、解決が難しい問題です。開発者が行った変更は最初にテストする必要があり、テストされていないコードを実際のデータベースにマージしたくないため、このようなソリューションをスケジュールすることはできません。私は現在、この問題を完全に解決するための一般的な解決策を書いているので、この質問は私にとって興味深いものです。
しかし当面は、Open DBDiff というオープンソースの製品を使用しています (Google で調べてみてください。見逃すことはできません)。ソース データベースとターゲット データベースを渡すと、ターゲットをソースと同じにするスクリプトが生成されます。アセンブリとユーザー ロールのコピーに問題があるようですが、すべてにおいて問題はありませんでした。