14

いくつかの階層データを持つ新しいプロジェクトを開始しており、現在、それをデータベースに保存するためのすべてのオプションを検討しています。

再帰クエリを許可するPostgreSQLを使用しています。また、クロージャーテーブルなどのリレーショナルデータベースのデザインパターンを調べ、neo4jなどのグラフデータベースソリューションを調べました。

私はそれらのオプションの間で決定するのが難しいと感じています。例:私のRDBMSで再帰クエリが許可されている場合でも、クロージャテーブルを使用することは理にかなっていますか?それは、保守性とパフォーマンスの点でグラフデータベースソリューションとどのように比較されますか?

ご意見・ご感想をいただければ幸いです!

4

2 に答える 2

10

再帰クエリを使用できる場合は、クロージャテーブル全体が冗長になります:)

別のテーブルと関連するトリガーの余分なIO(およびディスクスペース)を処理するよりも、一度理解する必要がある複雑な再帰クエリを使用する方がはるかに優れていると思います。

postgresで再帰クエリを使用していくつかの簡単なテストを実行しました。テーブルに数百万行ある場合でも、特定の子のすべての親を返すためのクエリは10ミリ秒未満でした。親のレベルにもよりますが、すべての子供を返すのも速かったです。クエリ速度自体ではなく、行をフェッチするディスクIOに依存しているように見えました。これはシングルユーザーで行われたため、負荷がかかった状態でどのように機能するかわかりません。テーブルの大部分をメモリに保持できる(そしてpostgresを正しくセットアップできる)場合でも、非常に高速になると思います。親IDでテーブルをクラスタリングすることも役立つようです。

于 2011-09-21T14:29:39.440 に答える
2

クロージャーテーブルのレベルフィールド(「被写界深度」)は冗長です。それを計算するのに必要な再帰クエリは1つだけです。それはそれを要約することについてです。

于 2011-09-21T10:46:51.577 に答える