データベースバージョン/スキーマではないデータの制御の変更？

Question

ここでいくつかの記事を読んだ後、私は開発チームのデータベースのバージョン管理が実際に非常に重要であることを認識しました。

これまでは、更新があるたびに単純なdump whole databaseを使用していましたが、1つのテーブルだけが変更された場合、1つのテーブルをダンプしてから再インポートすることができます。最高のものではありませんが、追加的な変更のためにはうまくいきます。まだまだ問題はありません。

今、私は作業中のプロジェクトのgitリポジトリに.mwb (Mysql Workbench diagram)ファイルを保存します。 次に、schema managementの場合はdbvをgitとともに使用します。各ブランチはプロジェクトに基づいて名前が付けられていますが、かなりうまくいきます。これにより、回路図の変更を元に戻したりロールバックすることができます。

ただし、表に含まれるデータはどうですか。どのようにこれを維持することができますか？多分私は古い方法に固執するほうが良いでしょう。私は、同じDB構造ではあるが違うデータのプロジェクトについては理解していますが、バージョン管理して管理する必要のある特定のデータベースデータを持つサイトについてはどうでしょうか。

また、データベースの変更が必要な、既にデプロイされているサイトのベースについてはどうすればシームレスにすることができますか。 update/alterスクリプトの使用を提案しているものもあり、デフォルト値などでうまく動作するものもあります。しかし、すべてのウェブサイトデータベースを変更する必要があるウェブサイトプラットフォームを変更し、そのデータをそのまま維持するとどうなるでしょうか？

Answer 1

私は主にビジネスアプリケーションの開発と構成管理に携わってきました。あなたの質問は、そのような環境における課題を代表するものです。たとえばMicrosoft Wordをアップグレードすると、すぐにすべてのドキュメントをdocからdocxに変更する必要はありません。また、文書には、より単純な構造の完全リレーションデータベースもあります。

ビジネスアプリケーションではそうではありません。ユーザはリリースをスキップし、データモデルの不正な変更を行い、システムは実行し続けて正しい番号を提供する必要があります。

独自のアプリケーション（最大600台のテーブル）これには分岐/マージが含まれますが、アプローチは手動で行うこともできます。データモデルは、構造化された方法でダウン書くことができ

バージョン管理データモデル

。たとえば、テーブルの内容（メタデータを含むテーブルにロードされるCSV）として、または使用中のバージョンを検出し、見逃している場合は列やテーブルを追加するコード（非自明な移行など）。

これにより、同時に複数のユーザーがデータモデルを変更することができます。

自動検出を使用すると（たとえば、「add_column」ではなく「verify_column」という名前のコールを使用します）、アップグレードを開始するリリース番号に関係なく円滑な移行が可能になります。このようなプロシージャは、変更対象の表を分析し、列が存在しない場合はalter table t1 add col1 number not null、列が存在する場合はalter table t1 modify col1 not nullなどの正しいDDLを発行します。

OracleおよびSQL Serverの場合、いくつかのサンプル手順を提供できます。 MySQLでは、インストールをWindowsとLinuxで実行できるようにするために、OSに依存しないクライアント側の言語を使用してこれをコーディングします。 Apache Antを使用していることがあります。

バージョニングデータ

我々は、次の4つのカテゴリにテーブルを分割：

• R：参照データ。アプリケーションサイトが実際にシステムを使用する前に提供しなければならないデータたとえば、総勘定元帳の勘定コードです。参照データは、生きていてもめったに変化せず、サイズが連続的に増加しません。内容は、アプリケーションが使用されているサイトのビジネスモデルを反映しています。
• T：トランザクションデータ。アプリケーションの使用中にサイトが登録、変更、削除するデータ。例えば、総勘定元帳のエントリ。トランザクションデータは0から始まり、連続的に増加します。企業が収入を倍増させると、取引データも倍増します。
• S：播種したデータ;現場でユーザーによって維持されていないが、開発当事者によって提供され管理されているデータ。本質的にこれはデータに変換されたコードです。たとえば、「F」は「女性」を表します。シードされたデータのエラーは、システムエラーにつながる可能性があります。
• O：残り（技術的なので理想的ではありませんが、一部のシステムでは一時テーブルAまたはスクラッチテーブルBが必要です）。

カテゴリ 'S'（シードされたデータ）のテーブルの内容はバージョン管理下に置かれます。私たちは、通常これらをケースツールでメタデータとして登録し、「データセット」と命名しますが、Microsoft Excelやコードも使用できます。

たとえば、Excelでは、シードされたデータの行のリストがあります。列Aでは、=B..&"|"&C..& "|" & ...のようなExcel関数を入力して、すべてを連結し、ローダーツールによる読み込みに適したものにすることができます。

verifySeed('TABLE_A', 'CODE', 'VALUE') 

Excelは、複数のユーザーが同時に内容を変更することができ、バージョン管理下に持って来るために少し難しいです：

は、コードの例では、次のようなコールがある場合があります。コードによるアプローチは非常に簡単です。

不要なシードデータを削除する機能も追加してください。たとえば、廃止されたシードされたデータを明示的にリストするか、最後のインストールでは触れられていないがテーブルに存在するすべてのシードされたデータを自動的に削除します。

Answer 2

コードバージョンと同期しているトランザクションのジャーナルをデータモデルに保存する必要があります。情報を追加する各更新（新しいフィールド）では、 'ALTER TABLE x ADD COLUMN y ...'のような文を入力して、更新スクリプトにDEFAULT VALUE（おそらく関数付き）を指定するだけです。そしてダウンしたスクリプトのための 'ALTER TABLE x REMOVE COLUMN y ...'。テーブル内の情報を切り捨てる前に、データをエクスポートする必要があります。逆トランザクションの場合は、ダンプされたテーブルのデータをSQLに変換して、これらを使用して欠落した情報を追加することができます。

データモデル内の「ジャーナル」テーブルを使用して、適用されるスクリプトを示す簡単な序数を使用してこれらのトランザクションを追跡することができます。ソフトウェアがインストールされるときはいつでも、これらの数字を比較して、データを失うことなく、状態Nから状態Xへ、後方または前方へデータベースを移動するために再生するトランザクションのリストを作成することができます。