0

ネストされたセットを格納するテーブルがあります。collectionid で区別されたさまざまなネストされたセットを格納します (はい、ここで用語を混在させています。実際には、nestedsetid である必要があります)。次のようになります。

id | orgid | leftedge | rightedge | level | collectionid
1  | 123   |  1       |  6        |  1    |   1
2  | 111   |  2       |  3        |  2    |   1
3  |  23   |  4       |  5        |  2    |   1
4  |  67   |  1       |  2        |  1    |   2
5  | 123   |  3       |  4        |  1    |   2
6  | 600   |  1       |  6        |  1    |   3
7  |  11   |  2       |  5        |  2    |   3
8  | 111   |  3       |  4        |  3    |   3

もともと私は R ツリー インデックスを利用したかったのですが、これについて見たコードはLineString(Point(-1, leftedge), Point(1, rightedge))、collectionid を考慮しておらず、このid :1 とid :6 が最終的に同じ。

現在のセットアップで R ツリー インデックスを使用する方法はありますか? 同じテーブルに別のネストされたセットを含めることはできますか? 私の主な目的は、 MBRWithin および MBRContains関数を使用できるようにすることです。MySQL 5.1 の使用

4

1 に答える 1

0

1 次元データ (これらは 1d 間隔ですよね?) の場合、r ツリーよりも優れたインデックス構造が存在します。これらは 2 ～ 10 次元の動的データ用に設計されています (より高い次元では、分割戦略と距離関数がうまく機能しないため、パフォーマンスはあまり良くありません)。

実際、あなたのユースケースでは、クラシック SQL は非常にうまく機能するはずです。また、データベースはそのインデックスを効率的に利用できます。適切なインデックス構造を持つことは 1 つのことですが、データベースが持つインデックスを可能な限り活用する必要があります。

そのため、関数と関数にインデックスを付けるだけleftEdgeです。彼らは速いです！また、collectionid 列については、ビットマップ インデックスが適切です。rightEdge<, <=, >, >=

于 2012-08-18T07:20:31.650 に答える