PostgreSQLとMySQL：空間機能の比較
現在、空間データコンポーネントを含むWebアプリケーションを構築しています。最初に、空間データの比較は特定のポイントを取り、一致する重複する空間ポリゴンを返します。
そうは言っても、私たちのデータベースには、一般的なリレーショナルデータベースで見つかるすべての典型的なものを含む他の多くのコンポーネントがあります。
私たちは、使用するデータベースソリューションを選択する必要があるプロジェクトの段階にいます。
すべてのプロジェクトメンバーはMySQLの実装と管理に精通していますが、すべての調査では、特にpostGISを使用した空間データに関して、PostgreSQLがより良いソリューションであることが示唆されています。
私たちは、アプリケーションが多くの同時ユーザーで多くのアクションを経験することを期待しています（期待しています）。
空間データコンポーネントを使用してRDBMSとしてMySQLを使用した経験のある人は、長期的なアドバイス/経験を持っていますか？
親しみやすさを除いて、PostGISを使用することの欠点はありますか？
MySQLに対する利点/欠点について話すことはできませんが、PostGISコードは、（速度/機能性の観点から）最良であり、（テスト/現実世界での露出の観点から）最も成熟していると広く見なされています）利用可能です。
例として、FAAの何人かの人々が空港データベース（AeroNavなどがチャートの編集に使用）をOracleからPostgres/PostGISに変換することについてPGEast 2010で講演がありました。
avationDBサイト もPostgres（8.0）の上に構築されています。
GIS関連のクエリがあなたがしていることの中心にある場合、私の提案はPostgresを使用することです。リレーショナルデータベースで通常行う他のすべてのことも確実に処理できます。
MySQLからの切り替えに関しては、Postgresの背後にある documentation が一流であり、Oostgres Wikiのセクション MySQLからPostgresへの切り替えについて もあります。
最初の学習曲線は少し急で、データベースとストアドプロシージャを調整する必要がある場合があります（すでにMySQL向けに記述している場合）。しかし、それは乗り越えられない作業ではありません。
あなたは数週間で切り替えを行うのに十分なものを手に入れることができるはずです、そして開発データベースを設定した場合、おそらく1か月以内の日常的なタスクに精通していて、マニュアルのどこを見ればよいか確信があります。それほど日常的なものではありません。
いくつかの非常に重要なことを言えば。 MySQLとMariaDBにはまったく存在しないPostGISのサポートのリストを次に示します。
- 計算でSRIDを使用すると、ポイントに別のSRIDを指定すると、別の値が返されます。これはプロップ集約関数です。私の知る限りでは、MySQLは空間集約関数を提供していません
K最近傍：KNNをサポートしているのはPostGISのみです。インデックスのみを使用して任意のポイントに最も近いポイントを見つけます。すべてのポイントからの距離を計算する必要はありません。 MySQLは仕様に違反し、2つの値が同じSRIDを持っていることのみをチェックします。 PostGISには、シームレスなSRID認識を可能にする pro4j定義 のデータベースが付属しています。 SRIDを設定してST_Transform（ MySQLにはない関数 ）を呼び出すと、座標が再投影されます。
MySQLでは、実際のSRID値に関係なく、すべての計算はSRID 0を想定して行われます。 SRID 0は、軸に単位が割り当てられていない無限の平坦なデカルト平面を表します。将来、計算では指定されたSRID値が使用される可能性があります。 SRID 0の動作を保証するには、SRID 0を使用してジオメトリ値を作成します。SRIDが指定されていない場合、SRID 0は新しいジオメトリ値のデフォルトです。
ラスター ：ラスターの生成から抽出まで、ここには多くの機能があります。ヒートマップなどを生成できます。
Geography 、PostGISは、デカルト数学をまったく使用しない非投影地理タイプをサポートしています。それは、扁球の球体で動作する関連する機能の全体的に遅いです。 逆に、MySQLは2つのポイントから地理的なSRSに境界ボックスを作成することさえできません。
トポロジ 、ベクトルジオメトリとは異なり、トポロジジオメトリはノードと関係を格納します。ノードを移動すると、エッジも移動し、新しい面を取得します。これにより、エッジも強制的に方向付けられ、ルーティングに最適になります。サブポイントとして PgRouting が行うことの100％はMySQLでは使用できません-したがって、だけでは上にGoogleマップなどを作成できませんそれ。
ジオコーディング：国勢調査データを処理するcontribディレクトリに geocoder exstension があり、そのデータをインストールするローダーがあります。
アドレスの標準化：解析、保存、比較を簡単にするためにアドレスの正規化を処理する extension があります。
SQL-MMの機能 、
CIRCULARSTRINGCOMPOUNDCURVECURVEPOLYGONMULTICURVEまたはMULTISURFACEが見つからないMySQL。n-dコード：PostGISは3dm、3dz、4dの形状とポイントをサポートできますMySQL 単純にできません
MySQLはrツリーインデックスのみをサポートします。 PostGISはrツリー（Gist/gin）とBRIN（大きなジオメトリテーブルの場合）をサポートします
集計関数：私の知る限りでは、MySQLは 空間集計関数 を提供していません
K最近傍： PostGISはKNNをサポートしています のみ。インデックスのみを使用して、任意のポイントに最も近いポイントを見つけます。すべてのポイントからの距離を計算する必要はありません。
索引付け。 PostgreSQLでは、空間インデックス（Gist/ginインデックス）にデータを格納できます。たとえば、
year（または他の非空間データ）とgeomをsameに保存できます。インデックス。これを行う方法の詳細については、btree_ginおよびbtree_Gistを参照してください。
また、おそらく 200以上の関数 がPostGISでサポートされています。
要するに、MySQLはPostGISに独自のものを持たず、それを知っています。 PostGISは獣です。このことのいくつかを説明したかっただけです。
最初の回答のすべての記述に完全に同意しますが、自分の経験を共有します-私はこれを自国の国家道路管理局で作成しました：生産評論家、交通量の多いサイト。私は、MySQLとPostgreSQL/PostGISの両方でWebアプリをフィードすることをお勧めします。
すべての「典型的な」ものについて、WebアプリはMySQLベースのCMSで問題なく動作します。すべての空間タスクで、同じWebアプリがPostgreSQL/PostGISに基づいたカスタム開発で完璧に動作します。最初のコンポーネントは開発され、通常のMySQLスキルで簡単に保守されます。 2番目のコンポーネントには、最初はもう少し研究が必要でした。
あまり馴染みのないPostgreSQL/PostGISで、典型的なものの高価な全体の実装を強制する必要はありません。また、MySQLで地理空間のものの次善の実装を強制する必要もありません。すべてのプレイヤーにヒットできる場所でプレイさせます。