あなたが説明したように、標準的な緯度/経度のペアだけを処理し、すべての作業が単純なルックアップである場合、Geometry Type を使用しても速度が向上することはほとんどありません。
ただし、あなたが述べたようにもっと冒険したい場合は、ジオメトリ タイプを使用するように切り替えると、検索だけでなく、新しい可能性の全世界が開かれます。
たとえば、（私が取り組んでいるプロジェクトに基づいて）（英国のデータの場合）特定の地域のすべての町/村/都市のポリゴン定義をダウンロードし、相互参照を行って特定の町を検索するか、ロード マップがあれば、主要な配送ルート、高速道路、主要道路など、あらゆる種類のものの隣に住んでいる顧客を見つけることができます。
また、非常に高度なレポートを作成することもできます。町の地図を想像してください。各アウトラインが地図上にプロットされ、エリア内の顧客の密度を示す色で陰影が付けられています。いくつかの単純なジオメトリ SQL を使用すると、簡単にカウントが返されます。データベースから、この種の情報をグラフ化します。
次に、追跡があります。あなたがどのデータを扱っているのか、なぜ顧客を獲得しているのかはわかりませんが、何かを配達する場合、配達用バンの座標を入力すると、特定の顧客にどれだけ近いかがわかります.
質問は STDistance は速いですか?それは本当に言うのは難しいですが、「...に比べて速いですか?」という質問の方が適切だと思います。比較するものがない限り、はいまたはいいえと言うのは難しいです.
空間インデックスは、データを地理的に認識したデータベースに移動する主な理由の 1 つです。空間インデックスは、特定のタスクに対して最良の結果を生成するように最適化されていますが、他のデータベースと同様に、不適切なインデックスを作成すると、パフォーマンスが低下します。
通常のインデックスのように操作がかなり直線的であるのとは対照的に、並べ替えとインデックス作成の数学はデータの目的をより認識しているため、一般的に、ある種の速度の向上が確実に見られるはずです。
また、SQL サーバー マシンが強力であるほど、より良い結果が得られることにも注意してください。
言及する最後のポイントは、データの管理です。GIS 対応データベースを使用している場合、ArcMap や MapInfo などの GIS パッケージを使用してデータを管理、修正、視覚化する道が開かれます。つまり、修正は非常に簡単です。ポイント、クリック、ドラッグで行います。
私のアドバイスは、空間操作用にフォーマットされた既存のテーブルと並べてテーブルを作成し、いくつかのストアド プロシージャを作成してタイミング テストを行い、どれが最適かを確認することです。実行している基本的な操作だけで大幅な増加が見られる場合は、それが正当化されるだけです。それがほぼ同じである場合、決定は、実際に達成したい新しい機能にかかっています。