Mencampur tipe geometri dalam satu tabel PostGIS


24

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?


"Jenis" apa yang Anda bicarakan? Apakah itu POLYGON, LINE dan POINTS? Atau apakah itu jenis seperti "jalan", "sungai", dll?
Pablo

Maksud saya jenis geometri seperti Poligon, Garis dan Poin.
drnextgis

Jawaban:


24

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).


1
Demi kepentingan orang-orang yang kembali ke masalah ini sekarang: di PostGIS dalam Tindakan edisi kedua, ini dipindahkan ke bab 14.
yeedle

11

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).


1
Saya setuju dengan Anda bahwa skenario OP ini bisa dibilang kotor (kami tidak tahu cerita latar), tetapi Anda meninjaunya sedikit dramatis. Ini hampir bukan pergolakan besar yang Anda gambarkan sebagai. Saya tidak peduli apakah itu untuk penggunaan sehari-hari atau untuk ETL ke dalam sistem / arsitektur baru, semua ini dapat disederhanakan dengan mudah dengan beberapa tampilan dan beberapa indeks yang tepat, dan ini dapat ditulis dalam hitungan menit .. . bahkan jika ada beberapa lidnilai unik .
Elrobis
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.