PostgreSQLとMySQL：空間的特徴の比較

現在、空間データコンポーネントを持つWebアプリケーションを構築しています。空間データの比較では、最初に特定のポイントを取得し、一致する重複した空間ポリゴンを返します。

そうは言っても、私たちのデータベースには、一般的なリレーショナルデータベースで見られるすべての典型的なものを含む他の多くのコンポーネントがあります。

私たちはプロジェクトで、使用するデータベースソリューションを選択する必要があります。

すべてのプロジェクトメンバーは、MySQLの実装と管理に精通していますが、すべての研究では、特にpostGISを使用した空間データに関して、PostgreSQLがより優れたソリューションであることが示唆されています。

私たちのアプリケーションが多くの同時ユーザーで多くのアクションを体験することを期待しています。

空間データコンポーネントを使用してRDBMSとしてMySQLを使用した経験がある人には、長期的なアドバイスや経験がありますか？

PostGISを使用することの不便さはありますか？

MySQLに対する利点/欠点について話すことはできませんが、PostGISコードは（速度/機能の点で）最高の1つであり、テスト/実世界での露出の点で最も成熟したものの1つと見なされています）利用可能。

例として、FAAの一部の人々がPGEast 2010で、空港データベース（AeroNavなどがチャートをコンパイルするために使用）をOracleのPostgres / PostGISに変換することについて講演しました。avationDBサイトはまた、Postgresの（8.0）の上に構築されています。

GIS関連のクエリがあなたがやっていることの中心にあるなら、私の提案はPostgresを使うことです。リレーショナルデータベースで通常行う他のすべてを確実に処理できます。

MySQLからの切り替えに関して、Postgresの背後にあるドキュメントは一流であり、MySQLからPostgresへの切り替えに関する Oostgres Wikiのセクションもあります。
最初の学習曲線は少し急な場合があり、データベースとストアドプロシージャを微調整する必要がある場合があります（MySQL用にすでに記述している場合）が、それは乗り越えられないタスクではありません。

数週間のうちに切り替えを行うのに十分な能力があり、開発データベースをセットアップすれば、おそらく1か月以内に日常的なタスクに精通し、マニュアルのどこを参照したらよいか確信できます。あまり一般的ではない人のために。

いくつかの非常に重要なことといえば。MySQLとMariaDBにはまったくないPostGISがサポートするもののリストを以下に示します。

• 計算でのSRIDは、ポイントに異なるSRIDを与えると、異なる値が返されます。これはprop Aggregate関数です：私の知る限り、MySQLは空間集計関数を提供していません

K最近傍：PostGISのみがKNNをサポートします。インデックスだけを使用して任意のポイントに最も近いポイントを見つけます。すべてのポイントからの距離を計算する必要はありません！MySQLは仕様を破り、2つの値が同じSRIDを持つことのみをチェックします。PostGISにはpro4j定義のデータベースが付属しており、シームレスなSRID認識を可能にします。SRIDを設定して呼び出すST_Transform（MySQLにない関数）ことにより、座標が再投影されます。

MySQLでは、実際のSRID値に関係なく、すべての計算はSRID 0を想定して行われます。SRID 0は、軸に単位が割り当てられていない無限の平らなデカルト平面を表します。将来、計算では指定されたSRID値が使用される可能性があります。SRID 0の動作を保証するには、SRID 0を使用してジオメトリ値を作成します。SRID0がSRIDが指定されていない場合の新しいジオメトリ値のデフォルトです。

• ラスタ：機能のトンがラスタ世代からの抽出にここにあります。ヒートマップなどを生成できます。

• 地理、PostGISは、デカルト数学をまったく使用しない非投影地理タイプをサポートします。それは、扁球体で動作する関連機能の全体が遅いです。逆に、MySQLは2つのポイントから地理的SRSに境界ボックスを作成することさえできません。

• トポロジ、ベクトルジオメトリとは異なり、トポジオメトリストアノードとリレーション。ノードを移動すると、エッジも移動し、新しい顔が得られます。これにより、エッジが強制的に方向付けられ、ルーティングに最適になります。何のサブポイント100％としてPgRoutingがないでは、MySQLに利用できない-あなただけのようではないことができ、その上に、Googleマップなどを作成します。

• ジオコーディング：contribディレクトリに国勢調査データを処理するジオコーダー拡張と、そのデータをインストールするローダーがあります。

• アドレスの標準化：解析、保存、比較を容易にするためにアドレスの正規化を処理する拡張機能があります。

• SQL-MMは、特徴あなたは、単に見つけることができません、CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEまたはMULTISURFACEMySQLの中で。

• ndコード：PostGISは3dm、3dz、および4dの形状をサポートでき、MySQLは単にできない

• MySQLはrツリーインデックスのみをサポートします。PostGISはr-tree（gist / gin）とBRIN（大きなジオメトリテーブル用）をサポートします

• 集計関数：私の知る限り、MySQLは空間集計関数を提供していません

• K最近傍：PostGISのみがKNNをサポートします。インデックスだけを使用して任意のポイントに最も近いポイントを見つけます。すべてのポイントからの距離を計算する必要はありません！

• インデックス作成。PostgreSQLでは、空間インデックス（gist / ginインデックス）に任意のデータを保存できます。たとえば、保存することができますyear（または他の非空間データ）とgeomで同じインデックスを。これを行う方法の詳細btree_ginおよび参照してくださいbtree_gist。

また、PostGISでサポートされている機能はおそらく200以上です。

要するに、MySQLはPostGISに対して独自のものを保持しておらず、それを知っています。PostGISは獣です。このようなもののいくつかを説明したかっただけです。

私は最初の答えのすべての声明に完全に同意しますが、自分の経験を共有します-私はこれを自国の国家道路局で作成しました：生産評論家、交通量の多いサイト。MySQLとPostgreSQL / PostGISの両方でWebアプリをフィードすることをお勧めします。

「典型的な」ものすべてについて、WebアプリはMySQLベースのCMSで問題なく動作します。すべての空間タスクで、同じWebアプリが-完璧に動作します;）PostgreSQL / PostGISに基づいたカスタム開発。最初のコンポーネントは、通常のMySQLスキルで簡単に開発および保守されます。2番目のコンポーネントは、最初はもう少し研究に取り組みました。

あまり馴染みのないPostgreSQL / PostGISで一般的なもののコストのかかる実装全体を強制する必要はなく、MySQLでも地理空間のものの準最適な実装を強制する必要もありません。すべてのプレイヤーがヒットできる場所でプレイしましょう。