問題タブ [database-versioning]

職場では、いくつかの異なるプロジェクトで 4 人が一緒に働いています。プロジェクトごとに、それぞれが取り組んでいるローカル コピーがあり、その後、開発、ステージング、およびライブ デプロイがあり、さらにブランチ (Subversion を使用) があります。私たちのデータベースは MySQL です。

そこで私の質問は、データベースのどのリビジョンが各展開 (および開発者の場合はローカル コピー) に対して行われたかを管理する良い方法は何かということです。現在、各変更は、名前にタイムスタンプが付けられたテキスト ファイルに保存され、プロジェクトの下のフォルダーに配置されます。正直なところ、これはあまりうまく機能していません。何がどこに適用されたかを追跡するのに役立つソリューションが必要です。

バージョンを SQL Server 2005 データベースに配置し、これらに .NET アプリケーションからアクセスできるようにする必要があります。私が考えていたのは、「バージョン」という名前のデータベースで拡張プロパティを使用することであり、もちろん値はデータベースのバージョンになります。次に、SQL を使用してこれを取得します。私の質問は、これは良い計画のように聞こえますか、それとも SQL Server データベースにバージョンを追加するためのより良い方法はありますか?

メタデータを保持するためにテーブルを使用できないと仮定しましょう。

現在、データベースの変更管理プロセスを固める過程にあります。RedHat 5 で実行する MySql 5 を実行します。ツールとして LiquiBase を選択しました。これはオープン ソースであり、必要に応じて後で機能を拡張できるためです。また、まだアクティブな数少ない無料プロジェクトの 1 つでもあるようです。LiquiBase やその他の Db バージョン管理ツールを使用した経験のある人はいますか?

会社の背景: 私たちは、7/24 のホスト型アプリケーションを提供する SaaS 企業です。同じデータベースの異なるバージョンを実行している多数のインスタンスがあり、デプロイ プロセスが制御不能になり始めているため、デプロイ プロセスを管理する方法が必要です。データベースには数百のテーブルがあり、通常は 3 か月に 1 回リリースします。

昨年、Rails について読んだり遊んだりしたときに、最も印象に残ったツールの 1 つが Rake でした。すべての dev db を同じようにビルドに統合するデータベースのバージョン管理システム...そのようなものは、生活をとても簡単に (そして安全に) します!

しかし、私が把握できていないことの 1 つは、実稼働サーバーに実際にアクセスできない場合に、これらの変更をどのようにして実稼働サーバーに移動するのかということです。セットアップパッケージによってアプリケーションがインストール/アップグレードされる全国に複数のサーバーがあります。

注: この質問は、Rails/Rake 固有のテクノロジよりも戦略に関するものです。Rails は使用せず、.Net を使用します。しかし、このパブリッシュ シナリオを理解できれば、Migratordotnetなどのいくつかのツールがあり、似たようなことができる可能性があります。

データベーススキーマと変更のバージョン管理を開始する必要があることに気付いたところに到達しました。その結果、そのトピックに関するSOの既存の投稿を読みましたが、どのように進めるかがわかりません。

私は基本的に一人の会社であり、少し前まではコードにバージョン管理を使用していませんでした。私はWindows環境で、Aptana（IDE）とSVN（Tortoiseを使用）を使用しています。私はPHP/mysqlプロジェクトに取り組んでいます。

データベーススキーマをバージョン管理するための効率的で十分な（やり過ぎのない）方法は何ですか？

私はいくつかのプロジェクトでフリーランサーを1人か2人持っていますが、多くの分岐やマージが行われることは期待していません。したがって、基本的には、コードリビジョンへの同時スキーマを追跡したいと思います。

[編集]一時的な解決策：今のところ、タグをコミットするときはいつでも、スキーマダンプと必要な初期データを含む1つを作成することにしました（安定バージョン）。現段階ではそれで十分なようです。[/編集]

[edit2]さらに、increments.sqlという3番目のファイルも使用しています。ここでは、変更履歴を1つのファイルで簡単に追跡できるように、すべての変更を日付などで配置しています。時々、変更を他の2つのファイルに統合し、increments.sql[/edit]を空にします。

非常に大きなデータベース (5 GB 以上) で動作する Web アプリケーション プロジェクトがあります。データベース内のデータはプロジェクトごとに分割されています。各プロジェクトは約 1 GB かかり、アプリケーションが機能するための最小セットです (このデータセット全体に広がるいくつかの数学計算を行い、データセットの一部を削除することはオプションではありません)。

毎日のビルドの一環として、アプリをテスト環境にデプロイします。そのために、ビルダーは、現在の DB を適切なバージョンに更新するカスタム DB 更新ユーティリティを実行します。しかし、QA チームが「時間をさかのぼって」さまざまなビルドの計算結果を比較できるように、すべての毎日のビルドを保持する必要もあります。下位互換性のあるデータ スキーマを作ろうとしても、非常に困難で時間がかかる場合があります。したがって、質問は次のとおりです。

以前の毎日のビルドを維持して実行する必要があり、毎日のビルドを実行しながら大規模なデータベースを管理する必要がある場合、データベースのバージョン管理にどのようなアプローチを使用しますか?

違いがあれば、SQL Server 2005 と ColdFusion をフロントエンドに Java を使用しています。

SQLオブジェクトはVSSでどのように管理されますか？

SourceSafe/VSSをSQLServer2005と統合できますか？

SQLスキーマでバージョン管理が必要です。

SOポッドキャストのエピソード54で、 Jeffは、VisualStudioを使用してすべてのデータベースオブジェクトを個々のファイルに保存することについて話しました。これは、私のチームがデータベーススキーマの変更をTFSに適切に実装するために必要なもののように聞こえ、私はそれについてリードに話しました。彼はそれが素晴らしいアイデアだと考えています。

残念ながら、これまでのところ、これを機能させることができませんでした。私の問題の1つは、ローカルボックスにSQL Serverがインストールされていないことです（部門ポリシー）。私は明らかに何か間違ったことをしています。

誰かが私に手順の概要を教えたり、まともなリンクを提供したりできますか？

ありがとう！

こんにちは、

私は現在、.Netで記述され、データの永続性/ストレージにEntityFrameworkを使用している新しいプロジェクトの非常に初期の段階にあります。必要な機能の1つは、特定のモデルタイプを「バージョン管理」する機能です。たとえば、1つのモデルは1つの「要件」であり、n個の「要件バージョン」があり、基本的にその特定の「要件」インスタンスの履歴/ライフサイクルに戻る方法があります。すべてのリビジョンで静的でなければならない唯一のものは「ID」であり、他のすべては要件の存続期間を通じて完全に変更可能です。

ここで、Qは、「単に」Requirement >> RequirementVersion間に1：nの関係を作成する必要がありますか？その他の機能として必要なのは、古い状態を現在/最新の状態に完全に復活させる可能性、マイナーバージョンとメジャーバージョン（変更）などを備えた機能、そして最後に、「ベースライン」を作成する機能が必要です。後でその特定のベースラインに戻り、含まれているすべてのRequirementVersionsを表示するための、最新バージョンの要件のコレクション？

これは、数百万の要件レコードにスケールアップする必要があり、それぞれに数千のリビジョンがあります。これが特に私が求めている理由です。単純な1：n関係のスケーリングの側面など。

誰かが似たようなことをしたことがありますか、バージョン管理/ベースラインなどに関するいくつかの提案/ベストプラクティスなどがありますか？

乾杯＆ありがとう、-Jörg

バージョン管理を実装するための実行可能な戦略は次のとおりです (サンプル ドキュメント タイプとして「例」を使用)。

type フィールドが example_original という名前の元のドキュメントを 1 つ用意します。

ドキュメントに対するその後の変更はすべて、タイプ example_change と example_original ドキュメントの ID をキーとして持ちます。変更にはタイムスタンプも含まれます。

すべての example_change が「適用」された example_original の結果であるタイプ example_current の 1 つのドキュメントを保持します。新しい example_change ドキュメントは、このドキュメントに自動的に適用されます。

特定のバージョンを見つけるには、example_original doc を取得し、必要な変更を適用します (ほとんどの場合、特定のタイムスタンプまでですが、いくつかの変更を行うこともできます)。

私のユースケースには、オリジナルへの限られた数の変更が含まれることに言及する必要があります。ほとんどの更新は、新しいオリジナル ドキュメントで構成されます。これは私の現在のユースケースですが、多くの変更が関係する場合に生じる問題にも興味があります。

このアプローチには、どのような長所と短所がありますか?