Saya telah bekerja dengan ketiga database dan melakukan migrasi di antara mereka, jadi semoga saya masih dapat menambahkan sesuatu ke posting lama. Sepuluh tahun yang lalu saya ditugaskan untuk menempatkan -- 450 juta objek spasial -- kumpulan data besar dari GML ke database spasial. Saya memutuskan untuk mencoba MySQL dan Postgis, pada saat itu tidak ada spasial di SQL Server dan kami memiliki suasana startup yang kecil, jadi MySQL sepertinya cocok. Saya kemudian terlibat dalam MySQL, saya menghadiri/berbicara di beberapa konferensi dan sangat terlibat dalam pengujian beta dari fungsi yang lebih sesuai dengan GIS di MySQL yang akhirnya dirilis dengan versi 5.5. Saya kemudian terlibat dengan migrasi data spasial kami ke Postgis dan data perusahaan kami (dengan elemen spasial) ke SQL Server. Ini adalah temuan saya.
MySQL
1). Masalah stabilitas. Selama 5 tahun, kami memiliki beberapa masalah kerusakan basis data, yang hanya dapat diperbaiki dengan menjalankan myismachk pada file indeks, sebuah proses yang dapat memakan waktu lebih dari 24 jam pada tabel 450 juta baris.
2). Sampai saat ini hanya tabel MyISAM yang mendukung tipe data spasial. Ini berarti jika Anda menginginkan dukungan transaksi, Anda kurang beruntung. Tipe tabel InnoDB sekarang mendukung tipe spasial, tetapi tidak mengindeksnya, yang mengingat ukuran tipikal kumpulan data spasial, tidak terlalu berguna. Lihat http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Pengalaman saya dari pergi ke konferensi adalah bahwa spasial sangat ketinggalan jaman -- kami telah menerapkan replikasi, partisi, dll, tetapi tidak bekerja dengan spasial.EDIT:Dalam rilis 5.7.5 mendatang InnoDB akhirnya akan mendukung indeks pada kolom spasial, yang berarti bahwa ACID, kunci asing, dan indeks spasial akhirnya akan tersedia di mesin yang sama.
3). Fungsi spasial sangat terbatas dibandingkan dengan spasial Postgis dan SQL Server. Masih belum ada fungsi ST_Union yang bekerja pada seluruh bidang geometri, salah satu kueri yang paling sering saya jalankan, yaitu, Anda tidak dapat menulis:
select attribute, ST_Union(geom) from some_table group by some_attribute
yang sangat berguna dalam konteks GIS. Select ST_Union(geom1, const_geom) from some_table , yaitu, salah satu geometri adalah konstanta geometri hard-coded yang sedikit membatasi dibandingkan.
4). Tidak ada dukungan untuk raster. Mampu melakukan analisis raster vektor gabungan dalam db adalah fungsi GIS yang sangat berguna.
5). Tidak ada dukungan untuk konversi dari satu sistem referensi spasial ke sistem referensi spasial lainnya.
6). Sejak akuisisi oleh Oracle, spasial benar-benar tertunda.
Secara keseluruhan, agar adil untuk MySQL, itu mendukung situs web kami, WMS, dan pemrosesan spasial umum selama beberapa tahun, dan mudah diatur. Sisi negatifnya, kerusakan data menjadi masalah, dan dengan dipaksa menggunakan tabel MyISAM, Anda kehilangan banyak manfaat RDBMS.
Posting
Mengingat masalah yang kami miliki dengan MySQL, kami akhirnya mengonversi ke Postgis. Poin kunci dari pengalaman ini adalah.
1). Stabilitas ekstrim. Tidak ada kerusakan data dalam 5 tahun dan kami sekarang memiliki sekitar 25 kotak Postgres/GIS pada mesin virtual centos, dengan berbagai tingkat beban.
2). Laju pengembangan yang cepat -- raster, topologi, dukungan 3D menjadi contoh terbaru untuk hal ini.
3). Komunitas yang sangat aktif. Saluran irc Postgis dan milis adalah sumber yang bagus. Manual referensi Postgis juga sangat bagus. http://postgis.net/docs/manual-2.0/
4). Bermain sangat baik dengan aplikasi lain, di bawah payung OSGeo, seperti GeoServer dan GDAL.
5). Prosedur tersimpan dapat ditulis dalam banyak bahasa, selain dari plpgsql default, seperti Python atau R.
5). Postgres adalah RDBMS berfitur lengkap yang sangat sesuai standar, yang bertujuan untuk tetap dekat dengan standar ANSI.
6). Dukungan untuk fungsi jendela dan kueri rekursif -- tidak di MySQL, tetapi di SQL Server. Hal ini membuat penulisan kueri spasial yang lebih kompleks menjadi lebih bersih.
SQL Server.
Saya hanya menggunakan fungsionalitas spasial SQL Server 2008, dan banyak gangguan dari rilis tersebut -- kurangnya dukungan untuk konversi dari satu CRS ke CRS lainnya, kebutuhan untuk menambahkan parameter Anda sendiri ke indeks spasial -- kini telah teratasi.
1). Karena objek spasial di SQL Server pada dasarnya adalah objek CLR, sintaksnya terasa terbalik. Alih-alih ST_Area(geom) Anda menulis geom.STArea() dan ini menjadi lebih jelas ketika Anda merangkai fungsi bersama-sama. Hilangnya garis bawah pada nama fungsi hanyalah gangguan kecil.
2). Saya memiliki sejumlah poligon tidak valid yang telah diterima oleh SQL Server, dan kurangnya fungsi ST_MakeValid dapat membuat ini sedikit menyakitkan.
3). Windows saja. Secara umum, produk Microsoft (seperti yang ESRI) dirancang untuk bekerja sangat baik satu sama lain, tetapi tidak selalu memiliki kepatuhan standar dan interoperabilitas sebagai tujuan utama. Jika Anda menjalankan toko khusus windows, ini bukan masalah.
PERBARUI :setelah bermain sedikit dengan SQL Server 2012, saya dapat mengatakan bahwa itu telah meningkat secara signifikan. Sekarang ada fungsi validasi geometri yang baik, ada dukungan yang baik untuk tipe data Geografi, termasuk objek GLOBE LENGKAP, yang memungkinkan merepresentasikan objek yang menempati lebih dari satu belahan dan dukungan untuk Kurva Majemuk dan String Melingkar yang berguna untuk akurat dan kompak representasi dari busur (dan lingkaran) antara lain. Mengubah koordinat dari satu CRS ke CRS lain masih perlu dilakukan di perpustakaan pihak ketiga, meskipun ini bukan penghalang acara di sebagian besar aplikasi.
Saya belum pernah menggunakan SQL Server dengan kumpulan data yang cukup besar untuk membandingkan satu lawan satu dengan Postgis/MySQL, tetapi dari apa yang saya lihat fungsinya berperilaku dengan benar, dan meskipun tidak sepenuhnya ditampilkan seperti Postgis, ini adalah peningkatan besar pada penawaran MySQL .
Maaf atas jawaban yang begitu panjang, saya harap rasa sakit dan kegembiraan yang saya derita selama bertahun-tahun dapat membantu seseorang.
