私たちはこの問題について内部で少し対立しており、満足のいく結論に達することができないようです.
緯度と経度、および場合によっては単純なポリゴンのみを保存します。必要なのは 2 点間の距離を計算すること (そしておそらく点がポリゴン内にあるかどうかを確認すること) だけです。
私たちの要件は非常に緩和されているため、開発チームの半分SqlGeometryは明らかに単純な型を使用することを提案しています。ただし、地理データを保存しているので、これを受け入れるのに苦労しています。これは、それらをに保存するSqlGeographyのが正しいことのようです。SqlGeometryまた、データ型が型よりもはるかに扱いやすいという実質的な証拠は見つかりませんSqlGeography。
この比較的単純なシナリオにどのタイプがより適しているかについて、誰かアドバイスがありますか?
これは、機能、精度、単純さの比較の問題ではありません。2 つの空間データ型は、異なる種類のデータを操作するためのものです。
類推として、各行の一意の識別子を含む列に最適なデータ型を選択しているとします。その UID に整数値のみが含まれている場合はintを使用しますが、6 文字の英数字値の場合はchar(6)を使用します。また、可変長の Unicode 値がある場合は、代わりにnvarcharを使用しますよね?
同じロジックが空間データにも当てはまります。列に含まれる値に基づいて適切なデータ型を選択します。地理 (緯度/経度) 座標を使用している場合は、SqlGeographyデータ型を使用します。それはとても簡単です。
SqlGeometryを使用して緯度/経度の値を格納できますが、それはnvarchar(max)を使用して整数を格納するようなものです...そして、今後さらに問題が発生することを約束します(すべての面積計算が測定されたとき)度の二乗で、たとえば)
SqlGeography 型では、SqlGeometry よりも使用できるメソッドが少なくなっています (特に Sql 2008 では)。
たとえば、Sql2008 で多角形の重心を取得したいとします。ジオメトリにはネイティブな方法がありますが、地理にはありません。
また、次の制限があります。
また、利用可能な (私が知っている) ほとんどの API とライブラリは、地理よりも幾何学をうまく処理します。
とはいえ、距離の計算を正確にする必要がある場合、距離が長く、座標が世界中にある場合は、おそらく地理の方が適しているでしょう。それ以外の場合、問題の説明によると、ジオメトリ タイプで十分に機能します。
あなたの質問について：「それははるかに働きやすいですか？」. 場合によります。とにかく、経験則として、単純なシナリオでは通常、SqlGeometry を選択します。
とにかく、その決定についてあまり心配する必要はありません。他の型で新しい列を作成し、必要に応じてデータを移行するのは比較的簡単です。
SqlGeometry4 年後、データをではなく に保存するべきだったことが明らかになりましたSqlGeography。
なんで？
立法府の地図から情報をインポートしていましたが、そのデータは に保存されていましたSqlGeometry。特定の緯度/経度が特定の立法府の境界内にあるかどうかを判断する場合、ポイントが 2 つの境界に近い場合、一貫性のない結果が得られます。
これにより、境界に「近い」場所を特定し、それらが適切な地区に割り当てられていることを手動で確認するために、追加の作業を行う必要がありました。理想的ではありません。
話の教訓:データに依存している場合は、決定の指針となるようにデータが格納されているタイプを検討してください。