14

行レベルのコンテンツでバージョン管理を実行できるストレージエンジンタイプが存在するかどうか疑問に思っていました。たとえば、ID、名前、値、およびIDがPKである単純なテーブルがある場合、行354は（354、 "zak"、 "test"）v1として開始され、その後（354、 "zak"、 "これは値のバージョン2"）v2であり、ID = 354のselecthistory（value）のような行の変更履歴を確認できます。

これは一種の難解なことですが、変更が加えられるたびにこれらの個別の履歴テーブルと関数を書き続ける必要はありません...

4

10 に答える 10

3

監査機能をもっと探しているようです。Oracleおよび他のいくつかのDBMSには、完全な監査機能があります。しかし、多くのDBAは、トリガーベースの行監査を実装することになります。それはすべてあなたのニーズに依存します。

Oracleは、コマンドラインから簡単に構成できるいくつかの詳細な監査をサポートしています。

MySQLとしてタグ付けされているようですが、ストレージエンジンについて質問しました。とにかく、他の回答も同じことを言っているので、元々はフラッシュバック機能に関するものだったので、この投稿を削除します。

于 2010-03-23T20:52:16.537 に答える
3

明らかに、あなたは本当に MySQL ソリューションを求めているので、これはおそらくあまり役​​に立ちませんが、Oracle には Total Recall (より正式には Flashback Archive) と呼ばれる機能があり、現在手作業で行っているプロセスを自動化します。アーカイブは、変更が自動的に取り込まれ、単純なAS OF構文でクエリ可能な一連の圧縮されたテーブルです。

当然のことながら、彼らはそれに対して課金します。残念ながら、Enterprise Edition に加えて追加のライセンスが必要です。 詳しくはこちら（PDF）。

于 2010-03-23T20:58:16.867 に答える
1

Google DBエンジンであるビッグテーブルは、そのようなことをしていると思います.行の更新ごとにタイムスタンプを関連付けます.

たぶん、Google App Engine を試すことができます。

Big Table の仕組みを説明している Google の論文があります。

于 2010-03-23T21:20:55.947 に答える
1

CouchDB はすべての変更に対して完全なバージョン管理を行っていますが、それは NOSQL の世界の一部であるため、おそらく現在行っていることからかなりクレイジーなシフトになるでしょう。

于 2010-03-23T21:22:53.540 に答える
1

トリガーを使用して同様の動作を実現できます (「すべてのデータベースの変更をキャッチするトリガー」を検索してください) - 特に SQL92 を実装している場合INFORMATION_SCHEMA。

そうでなければ、mrjoltcolaに同意します

編集:MySQL とトリガーに関して言及したい唯一の落とし穴は、(私がダウンロードした最新のコミュニティ バージョンの時点で) ユーザー アカウントにSUPER権限が必要であり、少し見苦しくする可能性があることです。

于 2010-03-23T20:55:07.153 に答える
1

本Refactoring Databasesには、この問題に関するいくつかの洞察があります。

しかし、現時点では、慎重に変更を加えて手動で管理する以外に、実際の解決策はないことも指摘しています。

于 2010-03-23T22:21:21.317 に答える
1

Oracle と Sql Server はどちらもこの機能を呼び出しますChange Data Capture。現時点では、MySql に相当するものはありません。

于 2010-03-23T21:19:25.390 に答える
1

google's bigtable に関するウィキペディアの記事では、テーブルに時間ディメンションを追加することでバージョン管理が可能になると言及しています。

各テーブルには複数のディメンションがあります (そのうちの 1 つは時間のフィールドで、バージョン管理が可能です)。

また、bigtable タイプの dbms の Google 以外の実装へのリンクもあります。

于 2010-03-23T21:25:33.837 に答える
0

「それは一種の難解なことですが、変更が加えられるたびにこれらの個別の履歴テーブルと関数を書き続けなければならないことを打ち負かすでしょう...」

私は監査証跡（明らかにあなたが話していることです）を「難解なもの」とは呼びません...

そして：データベースの更新の履歴と現実の履歴にはまだ違いがあります。履歴データベーステーブルは、データベースの更新の履歴ではなく、現実の履歴を反映するために実際に使用する必要があります。

データベース更新の履歴は、DBMSによってログとジャーナルにすでに保持されています。データベースの更新の履歴を調べる必要がある場合は、すべての更新を反映するという十分な保証を提供できないアプリケーションレベルの構成ではなく、ログとジャーナルに頼る必要があります。

于 2010-03-23T23:42:46.953 に答える
0

これに対する 1 つの近似はテンポラル データベースです。これにより、過去のさまざまな時点でのデータベース全体の状態を確認できます。ただし、それがあなたの質問に完全に答えているかどうかはわかりません。時間 t1 で行 1 の内容を確認しながら、別の時間 t2 で行 2 の内容を確認することはできません。

于 2010-03-23T21:07:11.350 に答える