Il y a une question qui compare les capacités de diverses bases de données spatiales, SIG :PostGIS/PostgreSQL contre MySql contre SQL Server ? , où Postgis sort assez clairement vainqueur de MySQL.
Que vous utilisiez MySQL ou Postgis, vous feriez bien mieux, si vous le pouvez, de stocker vos valeurs de latitude et de longitude sous forme de géométrie/géographie (Point), en tant que fonctions pouvant être utilisées pour trouver des choses à proximité, ST_Distance , ST_Distance_Sphere et le plus obscur <-> opérateur , voir Trouver n voisins les plus proches pour Point donné à l'aide de PostGIS ? (par exemple l'utilisation) travaillent directement sur les colonnes de géométrie/géographie. Plus important encore, vous pouvez ajouter un index spatial , dont ces fonctions ont besoin pour fonctionner correctement, ce qui surpassera largement les recherches sur les colonnes de latitude et de longitude indexées séparément (cela dépendra de la taille de la table, mais augmentera à mesure que la taille de la table augmente),
Dans Postgis, vous pouvez convertir la latitude et la longitude en une géométrie avec :
alter table mytable add column geom (Geometry, 4326);
update mytable set geom = ST_SetSRID(ST_MakePoint(lon, lat), 4326)
create index ix_spatial_mytable_geom on mytable using gist(geom);
À ce stade, vous pourrez effectuer des requêtes très efficaces pour trouver des points proches d'autres points, en utilisant l'un des exemples des liens ci-dessus.
Vous pouvez faire des choses similaires dans MySQL, bien qu'il ne supporte pas un système de référence spatiale, c'est-à-dire le 4326 ci-dessus, ce qui signifie lat/lon, et il manque une fonction ST_MakePoint, vous devrez donc utiliser STGeomFromText et concaténer le lat/ lon ensemble pour faire un POINT. Il fait également tout en coordonnées planaires, comme Claudio et d'autres l'ont déclaré, ce qui n'est pas un problème avec Postgis.
Je m'excuse pour une réponse longue et un peu tangentielle, mais après avoir effectué diverses migrations entre bases de données sur de grandes quantités de données (MySQL, SQL Server et Postgres/GIS) et commis de nombreuses erreurs en cours de route, j'espère pouvoir vous lancer dans le bonne direction (et ajoutez un peu de pérennité, si vous voulez commencer à utiliser d'autres fonctionnalités spatiales, que Postigs a à la pelle).
