Mencampur tipe geometri dalam satu tabel PostGIS

Saya dihadapkan dengan masalah berikut. Saya harus bermigrasi dari database Oracle ke PostgreSQL + PostGIS. Saat ini semua geometri dari semua jenis disimpan dalam satu tabel dan setiap catatan berisi bidang "tutup" yang menunjukkan fitur dari lapisan yang sama.

Apa pro dan kontra dari penggunaan metode seperti itu? Haruskah saya memecah data menjadi beberapa tabel jika saya tidak perlu menggunakan database dengan perangkat lunak pihak ketiga? Bagaimana dengan kinerja kueri spasial, akankah indeks membantu saya?

Jika Anda tidak membutuhkan dukungan pihak ketiga dan jangan mengabaikan kebutuhan untuk meminta dengan mengetikkan mereka di tabel yang sama berfungsi dengan baik. Atau Anda dapat menggunakan model pewarisan seperti yang dibahas dalam bab 3 PostGIS dalam Aksi.

http://www.postgis.us/chapter_03_edition_1

Dari perspektif arsitektur, PostGIS tidak terlalu peduli jika dalam kueri digunakan beberapa tipe yang berbeda. Jika kinerjanya baik untuk Anda di Oracle, itu akan sama saja dengan kinerja yang lebih baik di PostGIS.

Ada 2 alasan untuk membaginya (dan dapat dilakukan nanti sesuai kebutuhan): 1) Mencegah orang dari memasukkan berbagai jenis yang tidak Anda inginkan seperti koleksi geometri, string melingkar, dan apa yang tidak (yang bisa Anda tentukan secara manual sebagai batasannya) )

2) Jika Anda memiliki satu miliar poin dan 1000 poligon, dan melakukan banyak hal dalam tes poligon, kecepatannya jauh lebih baik jika ketika Anda melakukan kueri dan melakukan gabungan Anda - hal ini bertentangan dengan tabel catatan miliar - hingga 1000 dibandingkan dengan tabel rekor satu miliar ke satu miliar. Ini akan menjadi kasus untuk setiap basis data spasial yang saya pikir (tidak spesifik untuk PostGIS). Itu berlaku untuk semua kueri relasional yang akan saya duga juga (tidak spesifik untuk kueri spasial).

Yang ini sangat mengganggu saya. Saya kira itu karena saya telah melihat terlalu banyak file CAD dengan data semua pada satu lapisan, hanya dibedakan berdasarkan warna.

Apa yang terjadi adalah pilihan antara mengatur data berdasarkan struktur , atau dengan atribut .

Dengan pilihan itu, saya akan selalu mengorganisir data saya melalui struktur data.

Sebagai permulaan, saat memproses data, Anda memiliki satu simpai lebih sedikit untuk melompati (misalnya memilih a, b, c dari tabel di mana id = X sebagai lawan untuk memilih a, b, c dari tabel di mana id = X DAN tutup = Y )

Kemudian, pertimbangkan mengapa basis data memungkinkan beberapa tabel - jika format data menawarkan struktur data tertentu Anda harus berpikir mereka akan memproses data lebih efisien jika Anda menggunakannya.

Tetapi masalah besar (bagi saya) adalah ketika Anda ingin memindahkan data dan masuk ke sistem lain. Maka saya pikir itu menjadi tantangan nyata, karena aplikasi akhirnya mungkin tidak menggunakan data dengan cara yang sama. Saya telah melihat begitu banyak orang yang berhenti dalam skenario ini.

Jadi - dalam pengalaman saya - Anda akan dapat menggunakan dan mentransfer data dua kali lebih efisien ketika memiliki model data yang layak (lebih dalam dan lebih terstruktur).