Oui, attendez toujours que les coordonnées fluctuent.
Bien que le bâtiment ne risque pas de se déplacer sur la surface de la terre, en utilisant les coordonnées comme identifiants / clés pour les adresses est une mauvaise idée car l'ensemble de données est va passer par - dessous vous:
La précision est une question de définition. Une adresse est-elle épinglée le plus précisément possible dans sa boîte aux lettres, ou sa plus grande structure, ou la porte d'entrée? Quelle porte d'entrée? Peut-être l'allée?
La précision décimale est une autre préoccupation. Est-ce 33.754208la même chose que 33.754209? Cela peut être corrigé en arrondissant, mais vous perdez ensuite la précision. Ajouter une précision décimale est un luxe que vous pourriez ne pas avoir. Quelle que soit la précision de votre décimale, elles sont susceptibles d'être différentes (en particulier compte tenu de la façon dont les ordinateurs comparent les types de flottants) même si elles sont "identiques". À ce stade, vous dépendez entièrement des détails d'implémentation de bas niveau.
Lorsque vous ne contrôlez pas l'ensemble de données et que vous utilisez un attribut physique pour saisir quelque chose, vous ne pouvez pas garantir que la clé ne changera pas. Mais c'est un problème car votre base de données s'attend à ce que l'identifiant soit unique et constant. Même si vous le mettez à jour, qu'en est-il des collisions avec un autre point de données?
Même si vous possédez l'ensemble de données, vous êtes soumis aux deux premiers problèmes. Les définitions et implémentations changent. Vous ne pouvez tout simplement jamais mettre à jour vos données de coordonnées, même pour une meilleure «précision», mais les adresses changent toujours, que vous le vouliez ou non, invalidant votre cache.
Ce que vous pouvez faire, cependant, c'est posséder la clé . N'utilisez pas de coordonnées comme identificateurs; attribuez plutôt une clé qui est garantie unique dans votre application ( ou peut-être dans le monde ) et ne la laissez jamais changer.
Chez SmartyStreets, je m'occupe beaucoup des adresses de géocodage. Par exemple, cette adresse est un défaut de construction. Il manque un numéro secondaire (appartement / suite). Bien que nos données soient au niveau du bloc (près du toit), si nous pouvions être aussi précis que possible, quelles seraient ses coordonnées? À l'heure actuelle, nous l'attribuons à 33.75425, -84.38721seulement quelques mètres de l'emplacement de Google Maps. Est-ce que ce devrait être une coordonnée différente si c'est le lobby contre une unité dans ce bâtiment? La réponse à cette question peut changer, modifiant ainsi l'ensemble de données sous-jacent. Et qu'en est-il des unités qui sont juste au-dessus l'une de l'autre (vous pouvez épingler un point dans un bâtiment, mais à quel étage vouliez-vous dire)? Google passe évidemment par les mêmes questions, et si les réponses changent, les coordonnées changent également.
En tant que tel, nous recommandons toujours aux utilisateurs de donner à l'adresse une clé qu'ils contrôlent pour l'identifier de manière unique et ne la modifient jamais.
Pourquoi?
Les adresses sont un gâchis. Ils peuvent aussi changer, surtout si vous commencez à vous poser des questions philosophiques sur "Qu'est-ce qu'une adresse signifie vraiment? Représente-t-elle un immeuble ou un résident? Ou une boîte aux lettres?" et lorsque vous commencez à considérer que les adresses sont temporelles, ce qui signifie qu'elles changent avec le temps, cela devient encore plus laid.
Nous entendons également parler de personnes qui essaient de hacher les adresses ou d'utiliser le code-barres du point de livraison comme identifiant. Ne faites pas cela, car même dans un format standardisé, les adresses peuvent changer et pourtant être toujours la "même" adresse. Et le code-barres du point de livraison, considéré à tort comme unique pour une adresse, est doublement coupable: il change et n'est pas nécessairement unique. Cool hein?
tl; dr Faites en sorte que votre base de données repose le moins possible sur l'adresse et les coordonnées réelles.