3

基本的に、次のようなシナリオがあります。

vertex --- vertex* --- vertex

ただし、頂点*はパスのこの時点で可変数の頂点を持つことができ、結果として

vertex --- vertex1 --- vertex
vertex --- vertex2 --- vertex
vertex --- vertexN --- vertex

Nこの頂点にたどり着くまで、何が起こるかわかりません。このノードを初めてトラバースすると、パスのこの時点でこの頂点のインスタンスがいくつあるかを任意の関数で判断できます。

プロパティとして記録Nするだけですか、それとも値が増分された中央の頂点を持つ追加Nの数のパスを作成しますか?

実際の例としては、(親ディレクトリを開くまで) 不明な数のフォルダーを持つファイル ディレクトリがあり、各フォルダーには 1 つのファイルが含まれており、各ファイル パスをトラバースする必要があります。

アップデート：

これは私が期待するものです：

(最初のトラバーサル、特別なプロパティを持つ頂点に遭遇 *)

A --- X* --- B

親 A と子 B に接続された同じ X 頂点の追加インスタンスを生成します。

A --- X1 --- B
 \--- X2 --/
  \-- X3 -/

また

   A --- X1 --- B
   A --- X2 --- B
   A --- X3 --- B

これで、トラバーサルが次のように行われます

A, X1, B
A, X2, B
A, X3, B

頂点インスタンスはX互いにまったく同じであり、インデックス整数を持っています。インスタンスの数は、最初の初期トラバーサル ( ) によって決まりますA, X*, B。X* は、3 または 50 または 100 の追加インスタンスを生成する場合があります。

ストレージについては、このインデックス値を X* に格納し、最大整数に達するまで毎回インクリメントすることを意味していNました。したがって、上記の例では、開始インデックスが 1 で最大値が 3 になります。これにより、中間に追加の頂点を挿入して A と B の両方に接続する必要がなくなります。ただし、これが生成されたすべてのパスをトラバースする必要がある私の場合に最適です。

4

2 に答える 2

2

だから私はあなたのユースケースを手に入れたと思います。

あなたは基本的にオプションが必要です：

  1. 頂点 "x*" を他の頂点に置き換えます。
    • 最初に、特別な属性を持つすべての頂点を検索する単純なクエリを実行します (このステップではトラバーサルを使用しませんが、この特別な属性のインデックスを使用すると、高速になるはずです)。
    • 次に、トランザクション内のそれらすべてを、対応する実際の頂点の数に置き換えます (このクエリを再度実行する場合は、「x*」頂点を削除することを忘れないでください)。
    • 3 番目に、組み込みのトラバーサル ステートメントをすべて使用できます。これは、クエリ構造がグラフによって表示されるためです。

プロ：

  • 実装が簡単。
  • データは期待どおりであり、属性の解析は必要ありません。アプリケーションに A から B への 5 つのパスがある場合、A から B への 5 つのパスが DB に保存されます。
  • なしで組み込み機能を多用できます (ArangoDB は、デフォルトですべてのエッジが物理的に存在することを想定しています)。

短所：

  • 冗長データ (X1 - Xn は相互のコピー) であるため、ここにデータを保存する場合は、同期を保つように注意する必要があります
  • より高いメモリ消費。
  • グラフ内のパスが増える => トラバーサル ステップが増える
  • オプション 2 よりもパフォーマンスが低下します。

オプション 2: 中間頂点を 1 つだけ保存し、特別な属性を利用する

  1. 頂点を格納するだけ X*
  2. 特別な属性をチェックする独自のビジターを実装します (説明から、パス上の最後の頂点 (X*) に特別な属性があるかどうかを頂点 B でチェックしたいと思います)。その場合、(AXB) の値を結果に n 回追加します。

プロ：

  • パフォーマンス
  • 冗長性なし

短所：

  • アプリケーションで X* を X1 - Xn に置き換えるロジックを実装する必要があります。
  • 独自のビジターを実装する必要があります
  • ドメイン モデルとデータベースのコンテンツの間にわずかな不一致があります

データセットのサイズに基づいて決定します。非常に小さなデータセットがあり、冗長性/パフォーマンスが問題にならない場合は、オプション 1 を使用します。これは、はるかにシンプルで手間がかかりません。大規模なデータセットがあり、高性能が必要な場合は、オプション 2 の方が適していると思います。

それが役立つことを願っています;）

于 2014-06-03T08:38:47.143 に答える