12

私はすべてのSOの質問、コーディングホラーの記事を読み、管理データをリビジョン管理するための最良の方法を探すために頭を悩ませました。それらはすべて機能し、ユースケースなどに基づいて適切な実装があります。私が本当に知りたいのは、なぜデータベースがデータレベルでのリビジョンをネイティブにサポートするように作成されていないのかということです。

私が困惑しているのは、APIがすでにトランザクションで実際に配置されていることです。トランザクションを開始し、一部のデータを変更して、コミットします。私たちはデータベースに対しても認証を行っているので、責任があります。私の会社は、タグに相当する会計目的で、データベース全体の月末バージョンを保存しています。これはRCSを悲鳴を上げませんか？

分岐は、データよりもスキーマに関して、データベースが非常に恩恵を受ける可能性があるものです。私は本当にデータだけを気にしているので、これは実装の難しさを大幅に増加させるので、タグとコミットだけに固執します。

データベースは非常にタイムクリティカルなアプリケーションであることがわかったので、不要なオーバーヘッドはすべて無視され、一部のデータベースは壮大なレベルで巨大であり、リビジョンはそのサイズを指数化するだけです。テーブルごとのオプトインリビジョン管理は、間違いなく、ミリ秒の余裕があり、データ履歴がある程度重要である中小規模の環境に適しています。コミット、ログ、復帰、差分、非難、タグ、チェックアウトが必要です。MF-ingリビジョン管理が必要です。

どこかに質問があります...

4

4 に答える 4

3

テンポラル データベースについて読むことができます。

Date、Darwen、および Lorentzos による「Temporal Data & the Relational Model」では、著者は、時系列データの追跡における問題を説明するために第 6 正規形を導入しています。

Richard Snodgrass は、時間データを処理するための SQL の拡張機能としてTSQL2を提案しました。

実装には次のものがあります。

于 2010-04-27T19:17:40.673 に答える
3

1 つのネイティブ ソリューションは、Oracle のFlashback Database (別名 Total Recall)です。これは Enterprise Edition への有料の追加料金ですが、かなりクールです。データのバージョンを保持したい限り透過的に保存し、古いバージョンのデータを照会するための構文を提供します。テーブルごとに有効にすることができます。

基本的に、Flashback DB は、トリガーを使用して追跡テーブルにレコードを格納するようなものですが、滑らかで高性能で、通常の作業には見えません。

于 2010-04-27T19:37:26.097 に答える
1

いくつかの DBMS は、エンジン レベルのバージョン管理メカニズムを実装しています。残念ながら、これにはベンダーに依存しない標準がないため、すべて独自仕様です。Oracle フラッシュバックについては既に説明しました。Microsoft の SQL Server の変更データ キャプチャ機能は、もう 1 つの機能です。

于 2010-05-05T20:49:08.843 に答える
0

あなたは私がパフォーマンスをしたいのを忘れました。DBMSは非常に低レベルのデータストレージメカニズムであり、数十億行のシステムでは、パフォーマンスが重要になる可能性があります。したがって、この種の監査システムが必要な場合は、使用可能なツール（トリガーなど）を使用して自分で構築できます。

ファイルシステムの場合と同様に、すべてのファイルがバージョン管理に適しているわけではありません。データベースでは、すべての行がバージョン管理に適しているわけではありません。

于 2010-04-27T19:09:17.923 に答える