データベース構造を変更するためのバージョン管理システムはありますか？

私はしばしば次の問題に遭遇します。

データベースに新しいテーブルまたは列を必要とするプロジェクトのいくつかの変更に取り組んでいます。データベースを変更し、作業を続行します。通常、私は変更を書き留めて、ライブシステムで複製できるようにします。ただし、変更したことを常に思い出すことはできません。また、書き留めておくことも常に忘れています。

だから、私はライブシステムにプッシュし、大きくない明らかなエラーが発生しますNewColumnX。

これがこの状況のベストプラクティスではない可能性があるという事実に関係なく、データベースのバージョン管理システムはありますか？特定のデータベース技術については気にしません。存在するかどうか知りたいだけです。MS SQL Serverで動作する場合は、素晴らしいです。

Ruby on Railsには、移行の概念、つまりデータベースを変更するための簡単なスクリプトがあります。

移行ファイルを生成します。これには、dbバージョンを上げるためのルール（列の追加など）とバージョンをダウングレードするためのルール（列の削除など）があります。各移行には番号が付けられ、テーブルには現在のデータベースバージョンが記録されます。

上に移行するには、「db：migrate」というコマンドを実行して、バージョンを確認し、必要なスクリプトを適用します。同様の方法で移行できます。

移行スクリプト自体はバージョン管理システムに保持されます。データベースを変更するたびに、新しいスクリプトをチェックインします。開発者はそれを適用して、ローカルデータベースを最新バージョンにすることができます。

データベースを作成するためにソースファイルを使用するという点で、私は少し古い学校です。実際には2つのファイル（project-database.sqlとproject-updates.sql）があり、1つ目はスキーマと永続データ用、2つ目は変更用です。もちろん、どちらもソース管理下にあります。

データベースが変更されると、最初にproject-database.sqlのメインスキーマを更新し、次に、ALTER TABLEステートメントなどの関連情報をproject-updates.sqlにコピーします。次に、更新を開発データベースに適用し、テストを行い、うまくいくまで繰り返します。次に、ファイルをチェックインし、もう一度テストして、本番環境に適用します。

また、私は通常db-Config-のようなテーブルを持っています：

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

次に、更新セクションに以下を追加します。

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

db_version唯一のデータベースが再作成されたときに変更されます、そしてdb_revision私のDBは、ベースラインから外れどれだけ離れているかの表示を提供します。

更新を個別のファイルに保存することもできましたが、すべてをまとめてマッシュし、切り取りと貼り付けを使用して関連するセクションを抽出しました。もう少しハウスキーピングが必要です。つまり、「：」を$ Revision 1.1 $から削除してフリーズします。

MyBatis（以前のiBatis）には、コマンドラインで使用するためのスキーマ移行ツールがあります。Javaで書かれていますが、どのプロジェクトでも使用できます。

優れたデータベース変更管理プラクティスを実現するには、いくつかの主要な目標を特定する必要があります。したがって、MyBatisスキーマ移行システム（または略してMyBatis移行）は次のことを試みます。

• 新規または既存のデータベースを操作します
• ソース管理システム（Subversionなど）を活用する
• 同時開発者またはチームが独立して作業できるようにする
• 競合が非常に目立ち、管理しやすいようにする
• 順方向および逆方向の移行を許可します（それぞれ進化、進化）
• データベースの現在のステータスに簡単にアクセスして理解できるようにする
• アクセス権や官僚制にもかかわらず移行を可能にする
• あらゆる方法論を使用する
• 優れた一貫した慣行を奨励する

Redgateには、SQLソース管理と呼ばれる製品があります。TFS、SVN、SourceGear Vault、Vault Pro、Mercurial、Perforce、Gitと統合します。

SQLデルタを強くお勧めします。機能のコーディングが完了したら、それを使用して差分スクリプトを生成し、それらのスクリプトをソース管理ツール（Mercurial :)にチェックインします。

SQLサーバーとOracleバージョンの両方があります。

Javaベースであり、jdbcをサポートするほぼすべてのデータベースで動作するはずのオープンソースツールliquibaseについて誰も言及しなかったのではないでしょうか。Railsと比較して、スキーマの変更を実行するためにrubyではなくxmlを使用します。ドメイン固有の言語のxmlは嫌いですが、xmlの非常に優れた利点は、liquibaseが次のような特定の操作をロールバックする方法を知っていることです

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

自分でこれを処理する必要はありません

純粋なSQLステートメントまたはデータのインポートもサポートされています。

ほとんどのデータベースエンジンは、データベースをファイルにダンプすることをサポートする必要があります。MySQLはとにかく知っています。これは単なるテキストファイルなので、Subversionまたは使用するものに送信できます。ファイルに対してもdiffを実行するのは簡単です。

SQL Serverを使用している場合、Data Dude（別名Visual StudioのDatabase Edition）に勝るものはありません。慣れてきたら、データベースのソース管理バージョンと本番バージョンのスキーマ比較を簡単に行うことができます。クリックするだけで、差分DDLを生成できます。

MSDNには、非常に役立つ説明ビデオがあります。

私はDBMS_METADATAとToadについて知っていますが、誰かがOracle用のData Dudeを思い付くことができれば、人生は本当にすばらしいでしょう。

バージョンコントローラーで最初のテーブル作成ステートメントを作成し、次にテーブル変更ステートメントを追加します。ただし、ファイルを編集するのではなく、理想的には、シーケンシャルな名前の変更ファイルを追加するか、「変更セット」として追加すれば、特定のデプロイメントのすべての変更を見つけることができます。

私が見ることができる最も難しい部分は、依存関係を追跡することです。たとえば、特定のデプロイメントでは、テーブルAの前にテーブルBを更新する必要があるかもしれません。

Oracleの場合、私はToadを使用します。これは、スキーマを多数の個別のファイル（たとえば、テーブルごとに1つのファイル）にダンプできます。Perforceでこのコレクションを管理するスクリプトがいくつかありますが、どのリビジョン管理システムでも簡単に実行できるはずです。

oracleパッケージDBMS_METADATAを見てください。

特に、次の方法は特に便利です。

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

それらがどのように機能するかを理解したら（かなり自明）、それらのメソッドの結果をソース管理下に置くことができるテキストファイルにダンプする簡単なスクリプトを書くことができます。幸運を！

MSSQLにこれほど単純なものがあるかどうかはわかりません。

コーディングと並行してdbリリーススクリプトを記述し、リリーススクリプトをSSのプロジェクト固有のセクションに保持します。dbの変更を必要とするコードに変更を加えた場合、リリーススクリプトも同時に更新します。リリース前に、クリーンなdev dbでリリーススクリプトを実行し（本番環境から構造をコピーしたもの）、最終的なテストを行います。

私は何年にもわたってこれを行ってきました-スキーマバージョンの管理（または管理の試み）。最善の方法は、使用しているツールによって異なります。Quest Softwareツール「Schema Manager」を入手できれば、良い状態になります。Oracleには、「スキーママネージャ」とも呼ばれる独自の劣ったツールがあります（あまり混乱していますか？）。

自動化ツールがない場合（Data Dudeに関する他のコメントを参照）、スクリプトとDDLファイルを直接使用します。アプローチを選択し、それを文書化し、厳密にそれに従ってください。いつでもデータベースを再作成する機能が好きなので、データベース全体（DBAの場合）または開発者スキーマ（製品の場合）の完全なDDLエクスポートを希望します-開発モード）。

All Arround AutomationsのツールであるPLSQL Developerには、Visual Source Safeで正常に動作する（ただし、優れていない）リポジトリ用のプラグインがあります。

ウェブから：

バージョン管理プラグインは、PL / SQL Developer IDE >>とMicrosoft SCC Interface Specificationをサポートするバージョン管理システムとの間の緊密な統合を提供します。>>これには、Microsoft Visual SourceSafe、Merant PVCS、MKS Source Integrityなどの最も一般的なバージョン管理システムが含まれます。

http://www.allroundautomations.com/plsvcs.html

ER Studioを使用すると、データベーススキーマをツールに戻し、それをライブデータベースと比較できます。

例：開発スキーマをER Studioにリバースします。それを本番環境と比較すると、すべての違いがリストされます。変更をスクリプト化するか、自動的にプッシュすることができます。

ER Studioでスキーマを取得したら、作成スクリプトを保存するか、独自のバイナリとして保存してバージョン管理に保存できます。スキームの過去のバージョンに戻したい場合は、チェックアウトしてdbプラットフォームにプッシュしてください。

Ruckusingと呼ばれるPHP5の「データベース移行フレームワーク」があります。私はそれを使用していませんが、例はアイデアを示しています。言語を使用してデータベースを作成する場合、必要に応じて、ソースファイルを追跡するだけで済みます。

Visual StudioでMicrosoft SQL Serverデータツールを使用して、SQL Serverプロジェクトの一部としてデータベースオブジェクトのスクリプトを生成できます。次に、Visual Studioに組み込まれているソース管理統合を使用して、スクリプトをソース管理に追加できます。また、SQL Serverプロジェクトでは、コンパイラを使用してデータベースオブジェクトを確認し、既存のデータベースを更新または新規作成するための配置スクリプトを生成できます。

MS Team System Database Editionを使用して、かなりの成功を収めています。TFSバージョンコントロールおよびVisual Studioとほぼシームレスに統合し、ストアドプロシージャやビューなどを簡単に管理できるようにします。競合の解決は面倒な場合がありますが、バージョン履歴は完了すると完全になります。その後、QAへの移行と本番環境は非常に簡単です。

ただし、これはバージョン1.0製品であり、いくつかの問題がないわけではありません。

Oracleのスキーマ比較は、Oracleデータベースから別のデータベースに変更を移行するために特別に設計されたツールです。以下のURLにアクセスしてダウンロードリンクにアクセスし、ソフトウェアを完全に機能するトライアルに使用できます。

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

テーブル変更のためのVCSがない場合、私はそれらをwikiに記録してきました。少なくとも、いつ、なぜ変更されたかがわかります。誰もがそうしているわけではなく、複数の製品バージョンが使用されているため、完璧とは言えませんが、何もないよりはましです。

2つの方法のいずれかをお勧めします。まず、SybaseのPowerDesignerに投資します。Enterprise Edition。それはあなたが物理的データモデルをデザインすることを可能にし、そしてもっとたくさん。ただし、モデルをチェックインできるリポジトリが付属しています。新しいチェックインはそれぞれ新しいバージョンにすることができ、任意のバージョンを他のバージョンと比較したり、その時点でデータベースにあるものと比較したりできます。次に、すべての違いのリストを提示し、どちらを移行するかを尋ねます。次に、それを実行するスクリプトを作成します。安くはありませんが、2倍の価格でお買い得で、ROIは約6か月です。

もう1つのアイデアは、DDL監査を有効にすることです（Oracleで機能）。これにより、変更を加えるたびにテーブルが作成されます。最後にデータベースの変更を本番に移動したタイムスタンプからの変更をクエリすると、実行したすべての順序付きリストが表示されます。create table fooのようなゼロサムの変更を排除するいくつかのwhere句。続いてドロップテーブルfoo; そして、modスクリプトを簡単に構築できます。変更をwikiに保存する理由は、2倍になります。データベースにそれらを追跡させます。

2つの本の推奨事項：AmblerとSadalageによる「データベースのリファクタリング」とAmblerによる「アジャイルデータベーステクニック」。

誰かがRailsの移行について言及しました。Railsアプリケーションの外でも、うまく機能すると思います。Railsに移行中のSQL Serverを使用したASPアプリケーションでそれらを使用しました。移行スクリプト自体をVCSにチェックインします。これはPragmatic Dave Thomasによるこの件に関する投稿です。