製品カタログがあります。各カテゴリは、異なる数の (深い) サブカテゴリで構成されます。レベル数 (深い) は不明ですが、5.6 レベルを超えないことは確かです。データの変更は、読み取りよりもはるかにまれです。
問題は、どのタイプの階層データ モデルがそのような状況により適しているかということです。このプロジェクトは Django フレームワークに基づいており、その特性 (admin i-face、モデルの処理など) を考慮する必要があります。
どうもありがとう！
6838 次
5 に答える
5
Nested sets頻繁な更新や階層的な順序付けが必要ない場合は、パフォーマンスが向上します。
ツリーの更新または階層的な順序付けが必要な場合は、parent-childデータ モデルを使用することをお勧めします。
Oracleとでは簡単に構築できますSQL Server 2005+が、 ではそれほど簡単ではありません (ただし、可能です) MySQL。
于 2009-05-27T12:40:20.877 に答える
4
これらの記事によると：
http://explainextended.com/2009/09/24/adjacency-list-vs-nested-sets-postgresql/ http://explainextended.com/2009/09/29/adjacency-list-vs-nested-sets- mysql /
「MySQLはビッグ4（MySQL、Oracle、SQL Server、PostgreSQL）の中で唯一、入れ子集合モデルが適切なパフォーマンスを示し、階層データを格納していると見なすことができるシステムです。」
于 2010-08-15T05:23:19.643 に答える
4
この種の階層データには、Modified Preorder Tree Traversal アルゴリズム (MPTT) を使用します。これにより、ツリーのトラバースと子の検索で優れたパフォーマンスが得られますが、構造の変更に多少のペナルティが発生することを気にしない場合です。
幸いなことに、Django には、これに使用できる優れたライブラリdjango-mptt があります。私は多くの成功を収めた多くのプロジェクトでこれを使用しました。いくつかの代替アルゴリズムを提供するdjango-treebeardもありますが、私はそれを使用していません (とにかく mptt ほど人気がないようです)。
于 2009-05-27T13:46:04.113 に答える
1
隣接リストは保守がはるかに簡単で、ネストされたセットはクエリがはるかに高速です。
問題は常に、隣接リストをネストされたセットに変換するのに時間がかかりすぎることでした。これは、RBAR にロードされた非常に厄介な「プッシュ スタック」メソッドのおかげです。そのため、ネストされたセットで非常に難しいメンテナンスを行ったり、使用しなかったりすることになります。
これで、ケーキを持って食べることもできます！100,000 ノードで 4 秒未満、100 万行で 1 分未満で変換を実行できます。ちなみに、すべて T-SQL です。以下の記事をご覧ください。
于 2013-03-04T02:32:04.057 に答える
1
于 2010-07-12T11:36:54.710 に答える