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

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

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

サードパーティのサポートを必要とせず、タイプごとにクエリする必要性を予見しない場合、それらを同じテーブルに保持することはうまく機能します。あるいは、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つのレイヤー上のすべてのデータを含むCADファイルが多すぎるためです。

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

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

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

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

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

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