2

ほとんどがソース管理下にあるデータベース (SQL Server 2008 R2) があります (したがって、DB オブジェクトごとに 1 つのファイルが、テーブル、ビュー、ストアドプロシージャなどのフォルダーにグループ化されます)。現時点では、変更は SQL アップグレード スクリプトを記述して行い、次にいくつかの自作バッチ ファイルを実行して実行します (非常にエラーが発生しやすい)。

そのため、移行によって問題が解決するかどうかを調べていますが、ベスト プラクティスの適切な説明をまだ見ていません。ほとんどのブログ投稿は、空のデータベースを想定しているように見えますが、いくつかの移行 (通常は CreateUsers と CreateRoles) を行いますが、その後に何が起こるかを示していませんか? 何百ものストアド プロシージャがある場合、現在のようにそれらをオブジェクトごとの .sql ファイルに格納し、移行でそれらのファイルを参照する必要がありますか? 状態ベースの展開と移行ベースの展開を混同していませんか?

言い換えれば、移行に移行する場合、データベース全体を特定の既知の状態 (スナップショット #1) (数百のテーブルと数百のストアド プロシージャを含む) で作成する単一の SQL ファイルがあれば、大量の主要なプロジェクトの過程で移行し、そのプロジェクトの最後に新しいスナップショットを作成して、それをソース管理に追加しますか? VCS の唯一のものはスナップショットであり、スナップショット間を移動する移行ですか? しかし、個々のオブジェクトをバージョン管理していない場合、Users テーブルなどの履歴をどのように追跡できるのでしょうか?

4

1 に答える 1