0

データベース内の多くの異なるツリーのノードに関する情報を保存したいと考えています。

まず、500 のツリー間で共有される 20000 を超えるノードがあり、各ノードには 5 つの数値属性があります。構築された各ノードは、直接のすべての子への参照を必要とし、他のノードは参照しません。

初期化時にメモリ内にすべてのツリーを構築し、プログラムがダウンタイムに入ったらノードを更新/追加する必要があります (おそらく 1 時間ごとに、より良いですが)。

各テーブルを構築するのに時間がかかりすぎるように思われるSQL隣接モデル（db呼び出しが多すぎる）、可能性はあるがツリーを展開するのがより複雑なネストされたセットモデルを見てきました。非常に基本的な構造とクエリ セットである可能性があるため、データベースの複雑さが増します。

私はMongoDbも調べましたが、それはJSONタイプのオブジェクトに向けられているようで、Javaを使用していて、殺し過ぎている可能性があります.これは将来の可能性であり、DBへの書き込み時間を増やすことができます。これも利点です）

これについてどうすればよいか、誰か提案はありますか？

NoSql dbs はやり過ぎですか? ツリー構造の保存がはるかに優れていますか? それらをSQLデータベースと一緒に使用するのは悪い習慣ですか?

4

2 に答える 2

1

ネストされたセットで yields number of children プロパティを削除(rgt - lft - 1) / 2し、lft/rgt 列に float を使用すると、最小限の時間でノードを挿入/更新/削除できます。

そうするときの主な問題は、精度関連の問題を回避することです。後者を回避するには、lft/rgt を数値にキャストし、float に戻すことで、正規表現を取得できます。Postgres の例:

select (.1::float + .7::float) * 10::float;                          -- 8
select floor((.1::float + .7::float) * 10::float);                   -- 7
select floor(((.1::float + .7::float) * 10::float)::numeric::float); -- 8

もう 1 つの問題は、かなり簡単に管理でき、スペースが不足したときに発生します。その後、ツリーの一部またはすべてのインデックスを再作成する必要がある場合があります。ツリーをロックする必要がありますが、通常の操作に影響を与えることなく実行できるほど高速です。 .

于 2011-05-31T15:37:47.497 に答える
1

SQL Server 2008 以降を使用している場合は、そのようなシナリオ向けの新しいHierarchyIDデータ型を使用できます。

于 2011-05-31T15:55:22.737 に答える