テストからライブへのSQL Serverデータベースの展開

Question

2つのSQL Server間、具体的にはSQL Server 2005間でデータベースの展開をどのように管理しているのでしょうか。 今、開発とライブがあります。これはビルドスクリプト（標準のWindowsバッチ、これらのスクリプトの現在の複雑さにもかかわらず、PowerShellなどに切り替える可能性があります）の一部である必要があるため、Enterprise Manager/Management Studio Expressはカウントしません。

.mdfファイルをコピーして添付しますか？バイナリデータを扱うときは、（開発とライブでは常に同じバージョンのサーバを実行する必要がありますが）互換性の問題があるようですので、私は常に細心の注意を払っています。

T-SQLの "EXPLAIN CREATE TABLE"がないと、既存のデータベースをターゲットサーバー上で実行できるSQLスクリプトにエクスポートする作業を実行しますか？はいの場合、特定のデータベースをSQLクエリに自動的にダンプし、コマンドラインから実行されるツールがありますか？ （Enterprise Manager/Management Studio Expressはカウントしません）。

最後に、ライブデータベースにはすでにデータが含まれているため、すべてのテーブルを作成するのではなく、構造の違いを確認してライブのテーブルを変更する必要があります。既存のフィールドが変更されます。

今、私はRed Gate製品についてたくさんの素晴らしいことを聞いていますが、趣味のプロジェクトでは、価格は少し急です。

したがって、SQL Serverデータベースをテストからライブに自動的に展開するために使用しているのは何ですか？

Answer 1

私はすべてのDDL（作成/変更/削除）文をテキストファイルとして自分の.slnに追加し、通常のバージョン管理（Subversionを使用していますが、 。このようにして、私はバージョン管理の利点を得るだけでなく、dev/stageからのライブ更新もコードとデータベースの同じプロセスです。タグ、ブランチなどはすべて同じです。

それ以外の場合は、会社があなたのためにそれを購入していないと、私はredgateが高額であることに同意します。あなたがそれを買う企業を得ることができれば、それは本当にそれの価値がある！

Answer 2

私のプロジェクトでは、REd GateとMicrosoftのデータベース公開ウィザードとのSQL Compareを無料でダウンロードできます。 hereです。

ウィザードは、SQL CompareやSQL Data Compareほど滑らかではありませんが、そのトリックはありません。 1つの問題は、生成するスクリプトが一度にいくつかの並べ替えや編集が必要な場合があることです。

無料ツールでは悪くないスキーマとデータを上に移動できます。

Answer 3

Quest SoftwareのToadには、この種の管理機能が組み込まれています。基本的に2つのスキーマを比較して、1つのスクリプトから別のスクリプトに同期スクリプトを生成する2回の操作です。

もちろんSql Serverを含む多くの一般的なデータベースのエディションがあります。

Answer 4

私はソース管理で保持しているテキストファイルにテーブルを作成して変更するためのすべてのSQLスクリプトを保持することで、Karlと同じように動作します。実際には、スクリプトを変更し、実行するかを決定するために、ライブのデータベースを調べ持っていることの問題を回避するために、私は通常、次のように動作します：

• を最初のバージョンでは、私はすべてを置いて1つのSQLスクリプトにテスト中すべてのテーブルをCREATEとして扱います。これはテスト中にテーブルをたくさんドロップして読み込むことを意味しますが、プロジェクトの早い段階では大したことではありません（なぜなら、私はいつもその時点で使用しているデータをハッキングしているからです）。
• 次のすべてのバージョンでは、私は2つのことを行います。アップグレード用SQLスクリプトを保持する新しいテキストファイルを作成します。このファイルには、そのバージョンのALTERだけが含まれています。そして、私は元のものに変更を加えるだけでなく、新鮮なデータベーススクリプトを作成します。このようにしてアップグレードはアップグレードスクリプトを実行するだけですが、DBを再作成する必要がある場合は、そこに到達するために100のスクリプトを実行する必要はありません。
• 私はDBの変更をどのように配備しているかによって、通常、DBのバージョンを保持するDBにバージョンテーブルを入れます。次に、どのスクリプトを実行するかに関する人間の判断を下すのではなく、作成/アップグレードスクリプトを実行しているコードが何を実行するかを決定するためにバージョンを使用します。

テストからプロダクションに移行する部分がデータである場合に役立ちますが、構造を管理してすばらしいが高価なDB管理パッケージを支払う必要がない場合は、本当にそれほど難しいことではありません。私はそれがあなたのDBの精神的な追跡を維持するかなり良い方法であることも発見しました。

Answer 5

私はすべてをスクリプトすることが最善の方法であることに同意し、私が仕事で主張していることです。 DBやオブジェクトの作成からルックアップテーブルの作成まで、すべてスクリプトを作成する必要があります。

UIのみで行うことは翻訳されません（特に、最初の展開ではあまり変わらないので）。そして、Redgateのようなツールが必要になります。

Answer 6

SMO/DMOを使用すると、スキーマのスクリプトを生成するのが難しくありません。データは少し楽しいですが、まだ実行可能です。一般的に

、私は「スクリプトそれ」アプローチを取るが、あなたはこれらの線に沿って何かを検討する必要があります：

• あなたはデータのサブセットを開発できるよう、開発やステージングを区別する。..これは、私が単に生産データをプルダウンする、あるいはセキュリティが関係している偽のデータを生成するためのツールを作成するというものです。
• チーム開発のために、データベースへの各変更をチームメンバー間で調整する必要があります。スキーマとデータの変更は混在する可能性がありますが、1つのスクリプトで特定の機能を有効にする必要があります。すべての機能が準備できたら、これらを1つのSQLファイルにまとめて、実動の復元に対して実行します。
• ステージングが承認をクリアしたら、プロダクションマシンで単一のSQLファイルを再度実行します。

私はレッドゲートのツールを使用していると、彼らは素晴らしいツールですが、あなたがそれを余裕がない場合は、ツールを構築し、この方法で作業することは、あまりにも理想からかけ離れではありません。

Answer 7

Rob Allenと同様に、私はRedgateのSQL Compare/Data Compareを使用しています。また、Microsoftのデータベース公開ウィザードも使用します。私はまた、SQLスクリプトを使用してサーバー上で実行する、C＃で書かれたコンソールアプリケーションを持っています。この方法でコマンドラインやバッチスクリプトで 'GO'コマンドを使用して大きなスクリプトを実行できます。

私はMicrosoft.SqlServer.BatchParser.dllとMicrosoft.SqlServer.ConnectionInfoを使用します。コンソールアプリケーションのdllライブラリ

Answer 8

私はすべてをソース管理に保存し、すべての変更を手動でスクリプト化することに同意します。単一リリースのスキーマの変更は、そのリリース専用に作成されたスクリプトファイルに反映されます。格納されているすべてのprocs、viewsなどは、個々のファイルに格納され、ソース管理が行われる限り.csまたは.aspxのように扱われます。私はpowershellスクリプトを使用して、プログラム可能なものを更新するための大きな.sqlファイルを生成します。

新しいテーブルや新しい列などのスキーマ変更のアプリケーションを自動化するのは嫌いです。プロダクションリリースを行うときは、コマンドごとにchange scriptコマンドを実行して、それぞれが期待通りに機能することを確認します。あなたが開発に現れなかった少しの詳細を忘れてしまったので、プロダクションで大きな変更スクリプトを実行してエラーを出すことよりも悪いことはありません。

インデックスはコードファイルと同じように扱い、ソース管理に入れる必要があることも知っています。

あなたは間違いなく2つ以上のデータベースを持っている必要があります - devとlive。誰もが毎日の開発作業に使用するdevデータベースを用意する必要があります。その後、生産を模倣し、統合テストを行うために使用されるステージングデータベース。おそらく完成した最新のコピーを完全なバックアップから復元してもかまいませんが、それが実現可能であれば、インストールテストの最終ラウンドはできるだけ本物に近いものに向かいます。

Answer 9

問題のMicrosoftの解決策を忘れないでください：Visual Studio 2008 Database Edition。データベースへの変更を展開するためのツールを含み、スキーマおよび/またはデータの変更、ユニットテスト、テストデータ生成のためのデータベース間の差分を生成します。

かなり高価ですが、しばらく試用版を使用していて、華麗であると思いました。これにより、データベースは他のコードと同様に扱いやすくなります。

Answer 10

すべてのデータベース作成をDDLとして行い、そのDDLをスキーマメンテナンスクラスにラップします。私は最初にDDLを作成するためにさまざまなことを行うかもしれませんが、基本的にはすべてのスキーマをコードで行います。つまり、SQLにうまくマッピングされないDDL以外の処理を行う必要がある場合は、手続き型ロジックを記述してDDL/DMLの塊の間で実行することができます。

1. DBが存在しない：1、テストの比較的簡単なセットをコーディングできるよう

   私のDBSは、現在のバージョンを定義するテーブルを持っていますか？それを作成しない場合。

2. DBは現在のバージョンですか？そうでなければ、スキーマを最新のものにするメソッドを順番に実行します（この時点でバックアップを確認し、理想的にはバックアップを取ることをユーザーに促すことができます）。

単一のユーザーのアプリケーションの場合、バージョンが一致していない場合にユーザーをロックしているWebアプリケーションのために、これを実行します。マルチユーザの場合は、特定の環境に依存します。

利点はありますか？私は、この方法論を使用するアプリケーションのスキーマが、それらのアプリケーションのすべてのインスタンスで一貫しているという非常に高いレベルの自信を持っています。その完璧ではない、問題はありますが、それは動作します...

チーム環境で開発するときにいくつかの問題がありますが、それはとにかく与えられたものです。

Murph

Answer 11

私は上下2つの方法を、持っているsquentialためのクラスでDLLを持っているので、私は亜音速の移行メカニズムを使用しています。継続的な統合/ビルドスクリプトのナントがあるので、データベースの自動化を自動化できます。

これは世界で最高のものではありませんが、DDLを書くのに勝ちます。

Answer 12

RedGate SqlCompareは私の意見になる方法です。私たちは定期的にDBの展開を行います。私はそのツールを使い始めて以来、私は一度も振り返っていません。 非常に直感的なインターフェイスで、多くの時間を節約できます。

Proバージョンでは、ソースコントロール統合のスクリプトも処理されます。

Answer 13

私は現在あなたに同じことをしています。テストからSQL Serverデータベースを展開するだけでなく、ローカル - >統合 - >テスト - >プロダクションのすべてのプロセスを含めることができます。だから、毎日簡単にできるのは、NAnt task with Red-Gate SQL Compareです。私はRedGateのために働いていないが、それは良い選択だと言わなければならない。

Answer 14

また、私のすべてのオブジェクトとデータのスクリプトも保持しています。配備のために、私はこの無料ユーティリティ - http://www.sqldart.comを書きました。それはあなたのスクリプトファイルを並べ替えることができ、トランザクション内で全体を実行します。