6

すべてのDBDDLコードをCVSの下に置きたいのですが。

.NETコードにSubversionを使用していますが、すべてのデータベースコードはまだバージョン管理されていません。

私たちが知っているのは、DBロジックがいかに重要であるかということだけです。私はグーグルで検索しましたが、（高価なツール）はほとんど見つかりませんでした。他の（より安い）解決策があると思います。

どのようなアプローチに従うことをお勧めしますか？どのツールが最も適切ですか？

SQL Server 2005、VS 2008 TS、TSVN

更新 私たちのコーディングシナリオでは、開発者はPRODDBに直接アクセスできません。スクリプトによってのみ変更されます（したがって、これは問題ではありません）

私は主に、すべての開発者がフルアクセスできるDEV環境に興味があります。
そのため、開発者が以前に別の人によって変更されたUSPを上書きすることがあります。
紛失したバージョンを復元したり、USPのリビジョンを比較したりする可能性があります。

UPDATE-2
デプロイメントスクリプトを作成するために、Red-GateSQLCompareを使用しています。
完全に機能するため、展開スクリプトは当てはまりません。

4

9 に答える 9

4

まだ読んでいない場合は、MartinFowlerの記事EvolutionaryDatabaseDesignから始めるのが最適です。

この記事を要約するのは難しいですが、彼のチームが急速に変化する開発プロセスでデータベースのバージョン管理をどのように処理したかについて説明しています。彼らは物事を容易にするために独自のツールを作成しました：ユーザーを現在のマスターに近づけるためのスクリプト、ユーザーが互いの作業コピーをデバッグできるようにスキーマの任意のバージョンをコピーするためなど。

堅実なローテクソリューションの場合、2種類のDDLスクリプトをソース管理に保持すると便利であることがわかりました。

  • データベースオブジェクトを最初から作成できるマスターバージョン。
  • 各開発イテレーションの「バージョンアップグレード」スクリプト。

それらはある程度冗長ですが、非常に便利です（特に展開に関して）。

于 2010-01-12T15:03:47.807 に答える
2

Visual Studio Database Edition GDR（別名「DataDude」）をまだご覧になっていない場合は、必ずダウンロードして試してみてください。

http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en

特に、GDRは、各開発者がデータベースの独自のローカルコピー、バージョンスクリプトを維持し、データベーススキーマを新しいバージョンに移動するための展開スクリプトを作成し、データベースのロールバックをサポートすることを容易にすることで、チーム開発を促進します。

チームシステム開発者版を使用している場合は無料です。見てみな。

于 2010-01-12T15:21:47.610 に答える
1

最後に、このツールとアプローチは非常に便利で、導入が非常に簡単であることがわかりました
（少なくとも最初は、その場所にバージョン管理ソリューションがありません）。

http://www.codeproject.com/KB/database/SQLScripter.aspx

箱から出して実行できます。
最終的な解決策として、私はGDRに傾倒します。

于 2010-01-14T12:40:09.257 に答える
1

データベース内のオブジェクトごとにCREATEスクリプトを生成するSMOscriptを作成しました。

このツールを使用して、CVSの対象となるディレクトリに生成し、リポジトリを更新します。

于 2010-01-13T10:04:15.783 に答える
1

Visual StudioTeamSuiteまたはVisualStudioDeveloper Editionを使用している場合は、Visual StudioDatabaseProfessionalのコピーを利用できます。これは、あなたが説明したことなどを正確に実行するように設計されています。これを使用して、データベーススキーマ（コード）を管理します。

ランディ

于 2010-01-12T15:18:31.833 に答える
1

すべてのデータベースコードにもSubversionを使用しています。スクリプトに含まれていない限り、Prodにアクセスすることは許可されていないため、すべてのスクリプトを破壊することに問題はないようです。新しいデータベースを最初から作成する必要がある場合に備えて、テーブルの変更スクリプトを記述して既存のデータでテーブルを変更し、テーブル構造全体を再作成する傾向があります（一部のクライアントは非常に大きいため、複数のサーバーで同じデータベース構造を使用することがよくあります）また、競合他社が誤ってデータを利用できるようにしたくないため、別のサーバーに料金を支払うため、データなしでデータベース全体を再作成する必要がある場合があります。）データを直接保存しないオブジェクトの場合は、元のオブジェクトを削除して再作成します。 createステートメント。各プロジェクトにはリポジトリ内に独自のホームがあり、各データベースにもあります。

しかし、本当の鍵は、スクリプトなしでは誰もProdにロードできないということです。開発者にはprodに対する直接の権利を与えていないため、SSMSを使用するのとは対照的に、スクリプトで問題なく実行できます。

于 2010-01-12T15:30:50.540 に答える
1

これも面白そうですね。

フリーウェア： http：
//dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http：// blog.boxedbits.com/archives/133

コマーシャル：
http ：//www.nobhillsoft.com/Randolph.aspx

于 2010-01-13T09:52:18.567 に答える
1

Management Studio（SSMS）を使用し、.sqlをソース管理下に配置する必要があります。フォルダーの下にスキーマオブジェクトを分離することもできます。お役に立てれば

于 2010-09-28T14:02:32.817 に答える
0

Wizardbyがニーズに合っているかどうかを確認してください。

于 2010-01-13T09:54:32.483 に答える