4

各フォルダがバージョン履歴を保持する階層ファイル システムを検討してください(つまり、名前と追加のプロパティが変更される可能性があります)。これを に実装する必要がありMySQL 5.1ますが、将来のバージョンは に移植される可能性がありますSQL Server 2012。

データベースのツリー構造にはいくつかのオプションがあることを理解しています。

これらの手法は、以前に StackOverflow で説明されています。ただし、各ノードの履歴を維持する必要があるため、私の問題は問題に別の側面を追加します。維持する必要があるデータは、プロパティのリストとして見ることができます。例: 名前、日付、種類...

一部の敷地

  • データベースは、5 ～ 10 の同時クライアントを処理することが期待されています。
  • ツリーは、1000 ～ 5000 個の親ノード (葉の数は任意) まで成長すると予想されます。
  • ノードはいつでも挿入できます。
  • ノード/リーフが更新または削除されることはありません。代わりに、バージョン履歴が維持されます。
  • ノードの再編成は許可されていません。（ただし、可能であれば、これがあればいいのですが！）
  • 複数のクライアントが同時にツリー ノードを追加/変更する場合があります。したがって、クライアントはツリー構造を継続的に再読み取りする必要があります (リアルタイムの更新は必要ありません)。
  • 重要度: トレーサビリティ (重要)、パフォーマンス、スケーラビリティ。

Q: ツリー構造とそのバージョン管理されたノード データに最適な手法は何ですか? SQL サンプルは歓迎されますが、必須ではありません。

4

1 に答える 1

1

時変データを扱っており、提案したデータベース (または私が知っている他のデータベース) には、これを単純に行うためのネイティブサポートがないため、バージョニングは非常に注意が必要です。

SQL での時間指向データベース アプリケーションの開発を読んでください。この本はほぼ 15 年前のものかもしれませんが、問題はほとんど変わっていません。

「トレーサビリティ（重要）」に言及しているという事実は、これを正しく理解したいと考えていることを示唆しています。

階層のみを表示する単純なレポートを検討する場合、考慮する必要がある問題は次のとおりです。

  • 今日のデータを使用して、ツリーがどのように見えるか (はい、明らかに)
  • 先週のデータを使用して、ツリーが現在どのように見えるか
  • 今日のデータを使用して、1 週間前にツリーがどのように見えるか
  • 先週のデータを使用して、1 週間前にツリーがどのように見えるか
  • 先週のデータを使用して、1 週間前にツリーがどのように見えるか

直面する問題は、時変データを扱っているためです。データは、モデリングしている現実世界のプロセスとは異なる時間に更新され、それ自体が時系列データを扱っている可能性があります。とにかく本を読もう。

これが問題でない場合(つまり、ツリーが静的である場合)、@didirc のコメントは正しいです。ツリーのノードは外部のバージョン管理テーブルを参照できます。ただし、階層自体に関するバージョン管理情報も保存する必要がある場合、単純に実装した場合 (モデルを問わず)、このアプローチは機能しません。

具体的な例として、2013 年 1 月 1 日に有効な単純なツリー (A->B->C) を考えてみましょう。これが 1/2/13 に A->D->B->C に変更された場合。2013 年 1 月 3 日にクエリを実行し、2013 年 1 月 2 日を参照する場合、どのツリーを取得しますか?

幸運を

于 2013-04-04T06:30:12.140 に答える