私は3つのデータベースすべてを操作し、それらの間で移行を行ったので、古い投稿に何かを追加できることを願っています。 10年前、私はGMLから空間データベースに大きなデータセット（4億5000万個の空間オブジェクト）を配置するという任務を負いました。私はMySQLとPostgisを試してみることにしました。当時、SQL Serverには空間がなく、起動時の雰囲気も小さかったので、MySQLはぴったりのようでした。その後、MySQLに参加し、いくつかの会議に出席/講演し、バージョン5.5で最終的にリリースされたMySQLのよりGIS準拠の機能のベータテストに深く関わりました。その後、私は空間データをPostgisに移行し、企業データ（空間要素を含む）をSQLServerに移行することに携わってきました。これらは私の発見です。
MySQL
1）。安定性の問題。 5年間で、データベースの破損に関する問題がいくつか発生しました。これは、インデックスファイルでmyismachkを実行することによってのみ修正できました。このプロセスは、4億5,000万行のテーブルで24時間以上かかる可能性があります。
2）。最近まで、MyISAMテーブルのみが空間データ型をサポートしていました。これは、トランザクションサポートが必要な場合は運が悪いことを意味します。 InnoDBテーブルタイプは空間タイプをサポートするようになりましたが、空間データセットの一般的なサイズを考えると、それらのインデックスはそれほど有用ではありません。 http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.htmlを参照してください。会議に参加したときの私の経験では、空間は非常に後から付け加えられたものでした。レプリケーション、パーティショニングなどを実装しました。ただし、spatial.EDITでは機能しません。次の5.7.5リリースでは、InnoDBは最終的に空間列のインデックスをサポートします。つまり、ACID、外部キー、および空間インデックスが最終的に同じエンジンで使用できるようになります。
3）。空間機能は、PostgisとSQLServerの両方の空間と比較して非常に制限されています。ジオメトリフィールド全体に作用するST_Union関数はまだありません。これは、私が最も頻繁に実行するクエリの1つです。つまり、次のように記述できません。
select attribute, ST_Union(geom) from some_table group by some_attribute
これは、GISコンテキストで非常に役立ちます。 Select ST_Union(geom1, const_geom) from some_table つまり、ジオメトリの1つは、ハードコードされた定数ジオメトリであり、比較すると少し制限があります。
4）。ラスターはサポートされていません。 db内でベクトルラスター分析を組み合わせて実行できることは、非常に便利なGIS機能です。
5）。ある空間参照系から別の空間参照系への変換はサポートされていません。
6）。 Oracleによる買収以来、spatialは実際に保留されています。
全体として、MySQLに公平を期すために、MySQLは、当社のWebサイト、WMS、および一般的な空間処理を数年間サポートし、セットアップが簡単でした。欠点は、データの破損が問題であり、MyISAMテーブルの使用を余儀なくされることで、RDBMSの多くのメリットを放棄することになります。
Postgis
MySQLで発生した問題を考慮して、最終的にPostgisに変換しました。この経験の要点は次のとおりです。
1）。非常に安定しています。 5年間でデータの破損はなく、現在、さまざまな程度の負荷の下で、centos仮想マシン上に約25個のPostgres/GISボックスがあります。
2）。開発の急速なペース-ラスター、トポロジー、3Dサポートがこの最近の例です。
3）。非常に活発なコミュニティ。 Postgisircチャネルとメーリングリストは優れたリソースです。 Postgisリファレンスマニュアルも優れています。 http://postgis.net/docs/manual-2.0/
4）。 GeoServerやGDALなどのOSGeo傘下の他のアプリケーションと非常によく連携します。
5）。ストアドプロシージャは、PythonやRなどのデフォルトのplpgsqlとは別に、多くの言語で記述できます。
5）。 Postgresは、非常に標準に準拠した、フル機能のRDBMSであり、ANSI標準に近い状態を維持することを目的としています。
6）。ウィンドウ関数と再帰クエリのサポート-MySQLではなくSQLServerで。これにより、より複雑な空間クエリの記述がよりクリーンになりました。
SQLServer。
私はSQLServer2008の空間機能のみを使用しましたが、そのリリースの煩わしさの多く（CRSから別のCRSへの変換のサポートの欠如、空間インデックスに独自のパラメーターを追加する必要性）が解決されました。
1）。 SQL Serverの空間オブジェクトは基本的にCLRオブジェクトであるため、構文は逆に感じられます。 ST_Area（geom）の代わりにgeom.STArea（）を記述します。これは、関数をチェーン化するとさらに明白になります。関数名にアンダースコアを付けるのは、ちょっとした煩わしさです。
2）。 SQL Serverで受け入れられた無効なポリゴンがいくつかありますが、ST_MakeValid関数がないため、これが少し面倒になる可能性があります。
3）。 Windowsのみ。一般に、Microsoft製品（ESRI製品など）は相互に非常にうまく機能するように設計されていますが、標準のコンプライアンスと相互運用性を主な目的として常に持っているわけではありません。 Windowsのみのショップを運営している場合、これは問題ではありません。
更新 ：SQL Server 2012で少し遊んだことがありますが、大幅に改善されたと言えます。現在、優れたジオメトリ検証機能があり、複数の半球を占めるオブジェクトを表すことができるFULL GLOBEオブジェクトを含む、Geographyデータ型の優れたサポートと、正確でコンパクトに役立つ複合曲線と円形文字列のサポートがあります。とりわけ、円弧（および円）の表現。あるCRSから別のCRSへの座標の変換は、サードパーティのライブラリで行う必要がありますが、これはほとんどのアプリケーションでの目立たないものではありません。
私はPostgis/MySQLと1対1で比較するのに十分な大きさのデータセットでSQLServerを使用していませんが、関数が正しく動作することを確認したところ、Postgisほど完全には機能していませんが、MySQLの製品は大幅に改善されています。
長い回答で申し訳ありませんが、私が長年苦しんできた痛みと喜びの一部が誰かの助けになることを願っています。