ソース管理下のストアドプロシージャ、ベストプラクティス
現在、Tortoise SVNを使用して.NET Webアプリケーションをソース管理しています。 SQL Serverのストアドプロシージャをソース管理に組み込む最善の方法は何ですか？現在、開発環境としてVS 2010を使用しており、SQL Serverデータツール（SSDT）を使用して社外のSQL Server 2008 R2データベースに接続しています。
私がこれまでに行ったことは、プロシージャを.sqlファイルに保存し、このファイルをソース管理下に置くことです。これよりも効率的な方法があるはずだと思いますか？本番マシンのVS2010、SSDT、またはSQL Serverにインストールできる拡張機能はありますか？
this from Redgate などのツールは世の中にありますが、ソリューションのデータベースプロジェクト（SSDT？）でさえ、SQLファイルとして保存することをお勧めします。
これに加えて、次のガイドラインをお勧めします。
- 常にSVNのバージョンを「最新」/「最新」と想定する
- 実行するすべてのスクリプトに適切な「
if exists then drop" 開始時 - 必要に応じて、アクセス許可のスクリプトを作成してください
最初にSSMSから直接スクリプトを実行してこれらのSQLファイルを作成できます。また、すべての「drop」と「create」、および権限をスクリプト化するようにSSMSを設定できます。
SQLファイルをソース管理に保存すると、SQLファイルのみを制御できます。実際のデータベースオブジェクトの変更を制御することも、複数のユーザーが同じデータベースオブジェクトを同時に変更することも防止します（これも制御したいと思います）。私たちが使用しているのはサードパーティのツール（ ApexSQLバージョン ）で、SSMSとVSの両方と統合されています。オブジェクトのデータベースバージョンを使用するか、ソース管理バージョンを使用するかを選択できます。データベースのバージョンを編集している場合は、自動的にチェックアウトされるので、他のユーザーが編集することはできません（異なるユーザーからの変更はマージされません）。再度チェックインした場合にのみ、他のユーザーが変更できます。そして、あなたはあなたのSCライブオブジェクトのバージョンと異なるバージョンを持っていることができます（私は私がその日のために去り、編集を終えて次の日にそれをテストすることを計画するときにそれを使います）
Ankhsvn を試してみてください。強くお勧めし、無料です。
ホームページから：
AnkhSVNは、Microsoft Visual Studio 2005、2008、2010および2012のSubversionソース管理プロバイダーです。
AnkhSVNは、Visual StudioでサポートされているすべてのプロジェクトタイプにApache™Subversion®ソースコード管理サポートを提供し、Microsoft Visual Studio IDE内から直接最も一般的なバージョン管理操作を実行できます。
「保留中の変更」ダッシュボードは、開発プロセスにおける独自の洞察を提供し、ソースコードと問題管理機能への簡単なアクセスを提供します。深いソースコード管理（SCC）の統合により、開発に集中でき、AnkhSVNはすべての変更を追跡し、特定のニーズを効果的に処理するためのツールを提供します。
私はRedGateとVisual Studioの両方のデータベースプロジェクトを試しましたが、データベースプロジェクトにデータベース定義を保存することを好みます。データベースがソリューションの一部になるとすぐに、好みのソース管理プロバイダーを使用できます。ほとんどは、優れたVisual Studio統合を備えています。
SSDTツールを使用すると、データベース定義の「最新バージョン」が得られるため、スキーマの比較を簡単に行い、スキーマアップグレードスクリプトを生成できます。
つまり、スキーマは通常、式の一部にすぎません。実際には、データベースにはすでに多くのデータが含まれていることがわかります。そして、ユーザーはそれを失うと、かなりがっかりする傾向があります。
そのため、v1.0を公開するとすぐに、アップグレードスクリプトを維持する必要が生じます。これらにはスキーマの変更のみが含まれることもありますが、多くの場合、他のテーブルのコンテンツに基づいてデフォルトを作成する必要があり、データをシードするまで特定の制約を解放する必要があります。通常、スキーマをアップグレードするだけでは完全にカットされません。私の好みは、これらのアップグレードスクリプトをデータベースプロジェクトの別のフォルダーにも置くことです。これらは通常、「v1.0からv1.1へのアップグレード」のようになります。
私のデータベースには常に現在のバージョン番号を示す参照テーブルがあるので、互換性のないアップグレードをブロックできます。私のアップグレードスクリプトの最初のステートメントは、現在のバージョンをチェックし、それが予期されたものと異なる場合は救済します。
データベースプロジェクトのもう1つの利点は、同じスキーマに基づいて異なるデータセットを展開できることです。開発用、QAチーム用、ユーザー受け入れテスト用、および自動統合テスト用のさまざまなデータセットがあります。データベースプロジェクトは配置後スクリプトを1つしか持つことができないため、ここでの秘訣は、「マスター」プロジェクトを参照する新しいデータベースプロジェクトを作成し、カスタムデータセットをそのプロジェクトの配置後プロセスの一部にすることです。
これらは私の2セントでした。何を考えても、何よりも、それはあなたとあなたのチームにフィットし、うまくいけば一般的なタスクのほとんどであなたをサポートする必要があります。
RedGateソース管理を使用して、ソース管理に接続します。
http://www.red-gate.com/products/sql-development/sql-source-control/
SSMSをソース管理リポジトリに直接フックし、静的データをチェックインすることもできます。
魅力のように働く
自分でツールを書いてしまいました。
無料でダウンロードできます- http://www.gitsql.net
同じ最終目標を達成したい他の人々の助けになることを願っています。
SQL Serverをソース管理する方法を説明する記事は次のとおりです。 http://gitsql.net/documentation-04_SQL_Server_and_GIT
私はそれをできるだけ簡単にしようとしました。 （3画面）
- SQL Serverに接続する
- オブジェクトを選択
- / importにエクスポートするフォルダを選択しました
また、誤って-インポートまたはエクスポートする個々のオブジェクトを選択して選択できる機能を追加しました。これにより、開発中の作業が非常に簡単になります。
通常、ストアドプロシージャとテーブルに変更を加えてから、これら2つのオブジェクトをGITディレクトリにエクスポートします。
次に、ソースツリーを使用して視覚的に変更を確認し、問題がなければ、それらをbitbucketにコミットします。