Si vous ne gérez qu'une paire standard Lat/Lng comme vous le décrivez, et que tout ce que vous faites est une simple recherche, alors vous ne gagnerez sans doute pas beaucoup en termes d'augmentation de vitesse en utilisant le type de géométrie.
Cependant, si vous voulez devenir plus aventureux comme vous le dites, le passage à l'utilisation des types de géométrie vous ouvrira tout un monde de nouvelles possibilités, et pas seulement pour les recherches.
Par exemple (sur la base d'un projet sur lequel je travaille), vous pouvez (s'il s'agit de données britanniques) télécharger les définitions de polygones pour toutes les villes / villages / villes d'une zone donnée, puis faire des références croisées pour rechercher dans une ville particulière, ou si vous disposiez d'une feuille de route, vous pouviez trouver les clients qui vivaient à côté des principales routes de livraison, des autoroutes, des routes principales, etc.
Vous pouvez également faire des rapports très sophistiqués, imaginer une carte des villes, où chaque contour a été tracé sur une carte, puis ombré avec une couleur pour montrer la densité des clients dans une zone, une simple géométrie SQL vous renverra facilement un compte droit de la base de données, pour représenter graphiquement ce type d'informations.
Ensuite, il y a le suivi, je ne sais pas quelles données vous gérez, ou pourquoi vous avez des clients, mais si vous livrez quelque chose, en fournissant les coordonnées d'une camionnette de livraison, vous indique à quel point il est proche d'un client donné.
Quant à la question, est-ce que STDistance est rapide ? eh bien c'est difficile à dire vraiment, je pense qu'une meilleure question est "Est-ce rapide par rapport à .....", il est difficile de dire oui ou non, à moins que vous n'ayez quelque chose à comparer.
Les index spatiaux sont l'une des principales raisons de déplacer vos données vers une base de données géographiquement consciente. Ils sont optimisés pour produire les meilleurs résultats pour une tâche donnée, mais comme toute base de données, si vous créez de mauvais index, vous obtiendrez de mauvaises performances.
En général, vous devriez certainement voir une augmentation de la vitesse d'une certaine sorte, car les mathématiques dans le tri et l'indexation sont plus conscientes de l'objectif des données au lieu d'être simplement assez linéaires en fonctionnement comme un index normal.
Gardez également à l'esprit que plus la machine du serveur SQL est puissante, meilleurs seront les résultats que vous obtiendrez.
Un dernier point à mentionner est la gestion des données, si vous utilisez une base de données compatible SIG, cela vous ouvre la possibilité d'utiliser un package SIG tel qu'ArcMap ou MapInfo pour gérer, corriger et visualiser vos données, ce qui signifie que les corrections sont très faciles. à faire en pointant, cliquant et glissant.
Mon conseil serait de créer une table côte à côte avec votre table existante, qui est formatée pour les opérations spatiales, puis d'écrire quelques procs stockés et de faire des tests de synchronisation, voir qui sort le mieux. Si vous avez une augmentation significative uniquement sur les opérations de base que vous effectuez, alors c'est une justification à elle seule, si c'est à peu près égal, votre décision dépend vraiment de la nouvelle fonctionnalité que vous souhaitez réellement obtenir.
