Apakah geodatabase pribadi lebih cocok untuk dengan cepat menanyakan atribut yang diindeks daripada geodatabensi file?

Saya sedang menyiapkan data untuk aplikasi ArcGIS Engine yang menanyakan data untuk mencari alamat. Terkadang kita mencari di bidang nama jalan, di bidang nomor rumah, atau keduanya. Saat menggunakan geodatabase pribadi atau geodatabase SDE, seseorang dapat menambahkan indeks atribut multi-kolom sebagai tambahan pada indeks satu-kolom. Untuk beberapa alasan, menurut artikel ESRI membuat indeks atribut, indeks atribut multi-kolom tidak mungkin ketika menggunakan file geodatabases. Mereka tidak menyebutkan mengapa hal ini terjadi - mungkin file geodatabases tidak memerlukannya karena alasan tertentu?

Indeks multi-kolom pada bidang nomor rumah dan bidang nama jalan harus secara teoritis meningkatkan kinerja permintaan saya ketika mencari kedua bidang sekaligus, tetapi apakah itu layak beralih ke menggunakan geodatabase pribadi? Saya merasa bahwa kerugian menggunakan geodatabase pribadi mungkin meniadakan manfaat dari indeks multi-kolom.

Saya mendapat kesan bahwa Esri ingin kita pindah dari geodatabase pribadi, tetapi apakah ini kasus di mana geodatabase pribadi adalah pilihan yang lebih baik? Jika Anda memiliki pengalaman dengan ini, saya ingin tahu.

Untuk menjawab bagian pertama dari pertanyaan Anda, saya pikir akan membantu untuk melihat teks tambahan di file bantuan Membuat Atribut tentang indeks multi-kolom.

Urutan bidang mana yang muncul dalam indeks multikolom adalah penting. Dalam indeks multikolom dengan kolom A kolom sebelumnya B, kolom A akan digunakan untuk melakukan pencarian awal. Juga, indeks semacam itu akan jauh lebih berguna untuk kueri yang hanya melibatkan kolom A daripada untuk kueri yang melibatkan kolom B saja.
Buat indeks multikolom pada A dan B. Indeks ini biasanya akan lebih efisien untuk kueri yang melibatkan kedua kolom. Untuk kueri yang hanya melibatkan A, indeks ini akan lebih lambat daripada indeks pada A saja. Indeks ini tidak akan banyak berguna untuk permintaan yang hanya melibatkan B. Untuk mengkompensasi, Anda dapat membuat indeks tambahan pada B.

Kedua bagian ini menunjukkan bahwa indeks multi-kolom lebih baik untuk penggunaan khusus. Lebih lanjut, menggunakan indeks semacam itu untuk mengurutkan hanya pada salah satu kolom yang disertakan, sebenarnya dapat merusak kinerja. Untuk alasan ini, kemungkinan indeks kolom individual akan diperlukan untuk setiap atribut yang termasuk dalam indeks multi-kolom.

Saya menemukan tautan ke dokumen yang lama, tetapi menarik oleh ESRI, menyatakan 9 alasan untuk memilih File daripada GDB Pribadi . Sangat menarik karena secara khusus menyebut kinerja sebagai satu alasan. Bagian dari keuntungan kinerja ini adalah karena sistem penyimpanan berbasis file. Saya pikir ini juga bisa berperan dalam kurangnya dukungan multi-kolom. Tidak seperti di Personal GDB, yang merupakan file tunggal, indeks dalam File GDB disimpan sebagai file terpisah dalam struktur GDB. Ini berarti bahwa file indeks dan file atribut untuk suatu kelas fitur khusus harus dihubungkan dan diakses bersama. Saya bisa melihat di mana indeks multi-kolom akan mengarah ke bolak-balik antara file indeks dan atribut, dan berpotensi menyebabkan hit kinerja yang melebihi kenaikan kinerja pengindeksan.

Karena sudah ada keuntungan kinerja yang signifikan dengan File GDB daripada Personal GDB, itu mungkin tidak layak menerapkan indeks multi-kolom.

Dalam pengalaman saya bekerja dengan kedua jenis GDB, saya telah melihat Personal GDB berjalan sekitar 50% lebih besar dari file. Berdasarkan data yang Anda berikan mengenai File GDB Anda, jika Anda mengonversi ke PGDB, Anda mungkin akan mendapatkan ~ 300MB Personal GDB. Dari apa yang saya lihat, bekerja dengan database MS Access, baik di dalam produk ESRI, dan secara terpisah, adalah Anda mulai melihat penurunan kinerja setelah file ".mdb" meningkat secara signifikan melebihi ukuran 100MB.

Masalah lainnya kemungkinan adalah bahwa bahkan jika Anda dapat mempercepat pencarian atribut Anda, Anda akan melihat hit kinerja besar yang terkait dengan bergerak dalam bingkai data, dan menyegarkan tampilan. Lapisan tidak akan menggambar secepat jika berada di PGDB. Artikel ini yang membandingkan Jenis Geodatabases memberikan informasi lebih lanjut tentang perbedaan kinerja.

Seperti banyak hal lainnya, pilihan terbaik pada akhirnya akan mengarah pada kasus penggunaan Anda. Jika ada banyak operasi khusus basis data yang ingin Anda lakukan, seperti kueri dan pembaruan, yang dapat Anda lakukan di antarmuka Access, maka Personal GDB mungkin lebih baik. Jika Anda hanya berencana melakukan kueri, tetapi terutama akan memvisualisasikan data spasial, maka kinerjanya jelas berada di sisi File GDB.

Setidaknya ada 9 alasan utama untuk menggunakan File Geodatabase daripada Personal Geodatabase. Sayangnya, masih ada banyak alasan untuk mempertahankan PGDB lama; dilema Anda menjadi salah satunya. (tidak ada publikasi ESRI tentang topik ini)

Saya percaya tujuan utama FGDB melalui PGDB adalah kapasitas penyimpanan dan kinerja data spasial (kecepatan menggambar, pengambilan, pengindeksan spasial, query spasial, dll.) Daripada fungsi seperti multi-kolom "atribut" indeks dan fungsi SQL canggih lainnya yang biasanya merupakan bagian integral dari DBMS. (Yang berbasis MS Access PGDB adalah dan ESG asli FGDB tidak) Sebagai catatan; Batas ukuran file maksimum dari database MS Access adalah 2GB yang juga merupakan ukuran maksimum dari setiap PGDB tunggal. Sebaliknya, batas ukuran file FGDB adalah 1TB yang dapat digunakan untuk 256TB.

ESRI juga menyatakan bahwa: Sintaks yang Anda gunakan untuk membangun ekspresi SQL berbeda tergantung pada sumber data. Ini karena meskipun SQL adalah standar, tidak semua perangkat lunak database mengimplementasikan dialek SQL yang sama. dan file berbasis data Untuk query, termasuk berkas geodatabases, liputan, shapefile, INFO tabel, tabel dBASE, CAD, dan data VPF, Anda menggunakan dialek SQL dilaksanakan dalam ArcGIS yang mendukung subset dari fitur dan fungsi yang tersedia di personal dan Geodatase ArcSDE.

Dengan kata lain (dan PGDB dan ArcSDE GDB adalah bukti dari itu) jika basis data yang mendasari geodatabase mendukung fungsi ini maka harus tersedia . Ini mungkin mengapa Anda dapat membuat indeks multi-kolom dalam PGDB yang memiliki basis data MS Access. Sama dengan geodatabase ArcSDE mana pun dengan DBMS yang mendasarinya yang mendukung fungsi ini.

Adapun File Geodabase ; pada rilis 9.2 FGDB ESRI menyindir bahwa beberapa fitur dan fungsi ini dapat ditambahkan dalam rilis FGDB mendatang, dengan mengutip; "File geodatabases tidak mendukung semua fitur dan fungsi yang tersedia untuk geodatabase pribadi. Di ArcGIS 9.2, fungsi yang paling umum digunakan tidak didukung oleh file geodatabases termasuk DISTINCT, GROUP BY, dan ORDER BY, dan fungsi set AVG, COUNT, MIN, MAX, dan SUM tidak didukung di luar subqueries. Dukungan untuk beberapa di antaranya kemungkinan akan ditambahkan di rilis mendatang. "

Empat tahun kemudian pada versi 10 tidak ada fungsi dan fitur ini yang tersedia. ( Daftar fungsi yang tersedia )

Tampaknya FGDB adalah pekerjaan yang sedang berjalan dan perlu kemampuan pengindeksan multi-kolom sebanyak itu membutuhkan semua fungsi SQL DBMS yang diperlukan. Saya kira kita akan terjebak dengan PGDB sampai pengembang ESRI memutuskan bahwa penting untuk memperluas fungsinya ke FGDB.

Menghidupkan kembali utas / masalah ini, saya merasa bermanfaat untuk menggabungkan, jika memungkinkan, FGDB dan PGDB. Misalnya, membuat scratch-geodatabase menjadi PGDB sangat membantu kinerja kueri. Ukuran PGDB seharusnya tidak meningkat terlalu banyak, seperti yang disebutkan di atas.