13

ビュー、ストアド プロシージャ、および関数のスクリプト ファイルを SVN (またはその他の) リポジトリに保持する最良の方法について、実際の例を誰かが提供できますか。

明らかに 1 つの解決策は、すべての異なるコンポーネントのスクリプト ファイルをディレクトリまたはそれ以上の場所に配置し、単純に TortoiseSVN などを使用してそれらを SVN に保持することです。その後、変更が行われるたびに、Management Studio などにスクリプトをロードします。 . 私は本当にこれをしたくありません.

私が本当に好むのは、定期的に（毎晩？）実行できるある種のバッチスクリプトです。これにより、特定の時間枠で変更されたすべてのストアドプロシージャ/ビューなどがエクスポートされ、SVN にコミットされます。

アイデア？

4

10 に答える 10

10

リビジョン コントロールを適切に使用したくないようですね。

明らかに1つの解決策は、すべての異なるコンポーネントのスクリプトファイルをディレクトリまたはそれ以上の場所に置き、単純にTortoiseSVNなどを使用してそれらをSVNに保持することです

これがすべきことです。作業中のローカル コピー (新規開発、古い調整など) があり、単一のコンポーネント/手順/などが終了したら、プロセスを最初からやり直す必要があるまで、それらを個別にコミットします。

最後にコミットしてから「X」回経過したという理由だけで、半分しか完成していないコードをコミットするのはずさんであり、リポジトリを使用している他の誰かを悲しませることが保証されています。

于 2008-09-09T06:31:14.600 に答える
4

ストアド プロシージャは、他のコンパイル可能なコードと同じように扱うのが最善だと思います。コードはリポジトリにあり、チェックアウトして変更を加え、開発ツールにロードしてコードをコンパイルまたはデプロイします。

于 2008-09-09T06:29:40.457 に答える
4

バッチ ファイルを作成してスケジュールできます。

  • スクリプト ディレクトリの内容を削除します
  • ExportSQLScriptのようなものを使用して、すべてのオブジェクトをスクリプト/スクリプトにエクスポートします
  • SVNコミット

注: オブジェクトはソース管理下にありますが、データやその進行状況はわかりません (名前が変更されたフィールド、または 1 つの新しいフィールドと 1 つの削除されたフィールドですか?)。

このアプローチは、変更履歴を維持するのに適しています。しかし、もちろん、「本番ビルド」に自動的にコミットするべきではありません (壊れたビルドが好きでない限り)。

あなたはそれを求めていませんでしたが: このアプローチでは、現在の DB をアップグレードする一連のスクリプトも生成されません。初期作成スクリプトしかありません。データ進行と作成アップグレード スクリプトの記録は、基本的なソース コントロール システムを超えています。

于 2008-09-09T07:02:55.023 に答える
1

これにはRedgate SQL Compare をお勧めします。これにより、データベースのバージョンを比較し、変更スクリプトを生成できます。また、かなり簡単にスクリプト化できます。

于 2008-09-09T06:57:33.587 に答える
1

拡張された質問に基づいて、本当に DDL トリガーを使用したいと考えています。データベースの変更ログ システムを作成する方法について詳しく説明しているこの記事を確認してください。

于 2008-09-29T18:37:19.457 に答える
0

データベースのすべての関連部分を、SVN を使用するディレクトリ構造にダンプするためのユーティリティを作成しました。私はそれを Manager に取り込もうとはしませんでしたが、もし興味があれば、ここにあります: http://www.reluctantdba.com/dbas-and-programmers/sqltools/svnforsql2005.aspx

これは無料で、定期的に実行しているため、バグがあればすぐに修正されます。

于 2008-09-11T02:54:32.547 に答える
0

価格帯についてはわかりませんが、DB ゴーストはオプションになる可能性があります.

私はこの会社で働いていません（または製品を所有していません）が、同じ問題を調査したところ、この製品は非常に有望に見えました.

于 2008-09-09T06:47:24.827 に答える
0

もう少し説明的だったはずです。問題のデータベースは内部 ERP システム用であるため、データベースの多くのバージョンはなく、本番/テスト/開発のみです。変更要求、新しい凝った機能などを実行したら、スクリプトまたは一連のスクリプトを実行して、テスト データベースで問題の手順を更新します。それで問題がなければ、本番環境でも同じことを行います。

したがって、私は完全なスキーマ スクリプト自体を求めているわけではなく、ストアド プロシージャに対するさまざまな編集を経時的に追跡できるものだけを求めています。たとえば、PROCESS_INVOICE は何かを行います。3月にマイナーな方法で更新されます。しばらくして、たとえば 5 月に、まれに、顧客が二重請求される (またはその他の非常識なケース) ことが判明しました。この手順に時間の経過とともに何が起こったのかを確認できるようにしたいと思います。現在、ここでの開発環境のセットアップ方法はありません。変更しようとしています。

于 2008-09-09T07:50:44.067 に答える
0

Visual Studio Team Edition の一部である DBPro をお勧めします。データベースのすべての部分を Team Foundation Server に格納するため、および展開やデータベースの比較などのために、数か月間使用しています。

もちろん、他の誰かが言ったように、それはあなたの環境と価格帯に依存します.

于 2008-09-09T18:28:15.657 に答える
-2

SourceSafe と SQL Server の統合はいつでも試すことができます。クイック スタートは次のとおりです:リンク。これを使用するには、Managment Studio Developers Edition が必要です。

于 2008-09-09T08:07:36.990 に答える