1つのPostGISテーブルでジオメトリタイプを混合する


24

次の問題に直面しています。OracleデータベースからPostgreSQL + PostGISに移行する必要があります。現在、すべてのタイプのすべてのジオメトリが1つのテーブルに格納され、各レコードには同じレイヤーのフィーチャを示す「lid」フィールドが含まれています。

そのような方法を使用することの長所と短所は何ですか?データベースをサードパーティのソフトウェアで使用する必要がない場合、データを複数のテーブルに分割する必要がありますか?空間クエリのパフォーマンスはどうですか?インデックスは役立ちますか?


どの種類の「タイプ」について話しているのですか?ポリゴン、ライン、ポイントですか?それとも、「道路」、「川」などのタイプですか?
パブロ

ポリゴン、ライン、ポイントなどのジオメトリのタイプを意味します。
drnextgis

回答:


24

サードパーティのサポートを必要とせず、タイプごとにクエリする必要性を予見しない場合、それらを同じテーブルに保持することはうまく機能します。あるいは、PostGIS in Actionの第3章で説明されているように、継承モデルを使用することもできます。

http://www.postgis.us/chapter_03_edition_1

アーキテクチャの観点から見ると、PostGISはクエリで複数の異なるタイプが使用されているかどうかはあまり気にしません。Oracleで問題なく実行された場合、PostGISでもパフォーマンスが向上しないかのようになります。

それを分割する2つの理由があります(必要に応じて後で行うことができます):1)ジオメトリコレクション、円形文字列、その他のようにしたくない異なるタイプを挿入できないようにします(手動で制約を定義できます) )

2)10億個のポイントと1000個のポリゴンがあり、ポリゴンテストで多くのポイントを実行する場合、クエリを実行して結合を実行すると(10億に対して)1000レコードテーブルに対して速度が大幅に向上します10億から10億のレコードテーブル。これは、私が考える空間データベースの場合に当てはまります(PostGISに固有ではありません)。私が推測するすべてのリレーショナルクエリにも当てはまります(空間クエリに固有ではありません)。


1
今、これに戻って来る人々の利益のために:PostGISの中でアクション第2版では、これが14 CHに移動しました
yeedle

11

これは本当に私を困らせます。これは、色だけで区別された1つのレイヤー上のすべてのデータを含むCADファイルが多すぎるためです。

結局のところ、構造別にデータを整理するか、属性別にデータを整理するかの選択です

その選択を考えると、私は常にデータ構造を介してデータを整理することになります。

最初に、データを処理するときにジャンプするフープが1つ少なくなります(たとえば、id = X AND lid = Yのテーブルからa、b、c選択するのではなく、id = Xのテーブルからa、b、c選択ます

次に、データベースが複数のテーブルを許可する理由を検討してください。データ形式が特定のデータ構造を提供する場合、それらを使用するとデータをより効率的に処理できると考える必要があります。

しかし、(私にとって)大きな問題は、データを別のシステムに移動する場合です。エンドアプリケーションは同じ方法でデータを使用しない可能性があるため、それは実際の課題になると思います。このシナリオでは、非常に多くの人が動けなくなるのを見てきました。

ですから、私の経験では、適切な(より深く、より構造化された)データモデルがあれば、データを2倍の効率で使用および転送できます。


1
OPのシナリオは間違いなく汚い(バックストーリーはわかりません)ことであなたに同意しますが、あなたがそれをレビューしているのは少し劇的です。それは、あなたがそれを説明する激変の大変動ではありません。私はそれが日々の使用のためであるか、新しいシステム/アーキテクチャへのETLのためであるかは気にしません、この全体はいくつかのビューといくつかの適切なインデックスで簡単に単純化することができ、これらは数分で書くことができます。lid。複数の一意の値がある場合でも。
elrobis
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.