Qu'est-ce qu'un moyen universel de stocker une adresse / localisation géographique dans une base de données?
Quel est le format correct d'une adresse/emplacement géographique qui convient bien à n'importe quelle adresse sur la Terre? En ce moment, j'ai:
- pays
- ville
- rue
- nombre
- données texte (pour plus de simplicité)
- Zip *: français
- lat/lng
Mais je crois que je peux l'améliorer: il pourrait y avoir un état/région d'un pays ou quelque chose comme une région. Ou pas de région/région/état, par exemple, à Singapour ou à Hong Kong.
Il pourrait ne pas y avoir de rue, mais une route ou un boulevard ou autre chose. Un certain nombre de bâtiments peuvent être composés. Il pourrait y avoir un étage. Un numéro de chambre. Etc....
Google a développé une bibliothèque qui permet de valider les adresses postales pour chaque pays du monde, que vous pouvez utiliser pour concevoir un schéma pour stocker ces données.
Recherchez les champs obligatoires les plus courants dans les adresses de votre base de clients cible pour commencer, et au fur et à mesure que vous identifiez d'autres pays avec des exigences différentes, vous pouvez continuer à ajuster votre schéma.
La façon universelle de stocker une adresse/un emplacement géographique dans une base de données est la suivante:
[Address] nvarchar(max) not null
Cela nécessite le moins de code de programmation (et donc réduit les coûts de maintenance) et est entièrement compatible avec n'importe quelle adresse. Il y a cependant trois grands problèmes:
L'absence de validation des données signifie que le champ peut être utilisé à d'autres fins que le stockage de l'adresse. L'un des objectifs est une attaque DOS destinée à remplir l'espace de votre base de données en entrant 2 Go de données dans le champ d'adresse.
Les données ainsi stockées ne permettent pas de les traiter à des fins de veille économique et d'exploration de données. Par exemple, combien d'utilisateurs viennent d'Inde? Il n'y a pas de moyen facile de le savoir, car ces adresses ne seront pas normalisées.
Les utilisateurs peuvent entrer par erreur une adresse incomplète ou manifestement erronée.
Afin d'atténuer le premier problème, limitez le champ à ce que vous pensez être une limite raisonnable. Personnellement, je commencerais par 1000 caractères, puis je le réduirais en fonction de la longueur des adresses saisies par les premiers utilisateurs une fois que vous aurez obtenu un ensemble de données suffisamment volumineux.
Afin d'atténuer les deux autres problèmes, vous pouvez utiliser une API tierce qui analyse les adresses et vous présente les données contenant le pays, la ville, le code postal, etc. Si possible, l'API doit pouvoir afficher l'adresse sur une carte à l'utilisateur pour réduire le risque pour l'utilisateur d'entrer une adresse incomplète ou erronée: la plupart des utilisateurs savent où ils vivent, et voir une position différente sur une carte leur donnerait immédiatement un indice qu'ils devraient vérifier leur entrée.
Notez que quelle que soit l'API que vous utilisez, elle ne sera pas parfaite. Il trouvera la plupart des adresses, mais pas toutes. Cela signifie que si l'API indique que l'adresse n'existe pas, mais que l'utilisateur insiste pour que ce soit le cas, vous devez a priori faire confiance à l'utilisateur, même s'il se trompe.
Cela signifie également que vous devez toujours stocker l'entrée de l'utilisateur d'origine, côte à côte avec le résultat de l'API. Cela signifie que le schéma devient:
[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null
Il n'y en a pas.
Chaque pays a des formats d'adresse différents. Si vous avez de la chance, et ils ont un format du tout!
Évidemment, la latitude/longitude vous donnera un point sur le globe, mais ce n'est pas vraiment utile pour identifier des maisons individuelles. Prenons par exemple un bloc tour.
Votre meilleur pari est de vérifier le service postal de chaque pays pour un format officiel. Cela peut être idéal pour votre base de données backend. Mais vous devrez probablement le simplifier pour les utilisateurs finaux car il contiendra beaucoup plus de champs que la plupart des gens.
Le Royaume-Uni, par exemple, comprend des choses comme "localité à double dépendance", mais personne ne saurait ce que cela signifie si vous leur demandez.
Le seul format universel est d'avoir un seul champ de texte qui peut avoir plusieurs lignes de texte. Cela permettra toute adresse possible sur terre.
J'ai développé des solutions logicielles à utiliser dans de nombreux pays. Nous abordons ce problème en commençant par l'entité la plus grande en premier, c'est-à-dire que le pays a ensuite des champs jusqu'au moins commun ou le plus petit. Cela fonctionne bien pour tous les pays que nous avons expérimentés jusqu'à présent. Nous avons également un système intelligent de prévention des doublons et une fusion pour ceux qui ont en quelque sorte pénétré le système, car les utilisateurs sont très "créatifs". Dans la section d'administration, nous avons un ordre de champ d'adresse par paramètre de pays. c'est-à-dire que le Japon a le code postal/postal en premier, alors que le Royaume-Uni/États-Unis en dernier.
En général, nous utilisons:
- Pays
- Code postal/postal
- État/Province/Préfecture/Comté
- Ville/Village/Village
- Rue/route/bloc
- Nom/numéro du bâtiment
- Informations spécifiques/personnalisées
Une fois saisie et enregistrée, une version conjuguée peut être affichée en laissant les champs inutiles.
Comme je l'ai dit, cela fonctionne pour tous les pays dans lesquels nous avons des logiciels et est le résultat du développement depuis 1989.
J'espère que cela aide en quelque sorte ou au moins fournit un autre aperçu.
Comme déjà indiqué, le plus universel (mais peu pratique à valider et peut-être le moins utile) est un seul grand champ unicode.
Vous pouvez séparer le pays du reste de l'adresse et l'enregistrer comme code de pays ISO. Cela normaliserait le pays et offrirait une certaine utilité pour valider le reste de l'adresse.
Vous pouvez également séparer le code postal alias Code postal du reste de l'adresse. Cela aurait également une certaine utilité pour valider le reste de l'adresse et pourrait être utile (bien qu'imprécis) pour la géolocalisation. Par exemple: au Canada, vous pouvez identifier de façon unique toute adresse en spécifiant uniquement le code postal et le numéro de rue (alias numéro de maison); cela peut ne pas être vrai dans tous les pays.
Dédier des champs aux états/provinces ou villes commence à devenir plus problématique en raison des variations dans la façon dont chaque pays formule une adresse. J'ai mis en place des tables d'adresses ayant de tels champs parce que le public initial est concentré sur l'Amérique du Nord, sachant qu'un public international poserait un problème pour s'intégrer. Dans la plupart des cas, ils peuvent être "à cornes de chaussure", mais c'est un compromis délicat et potentiellement sujet aux pannes - certainement pas universel.
Contrairement à la réponse de Mitchdav, je déconseille d'utiliser la bibliothèque de Google. J'ai cherché dans le référentiel divers endroits internationaux avec des schémas d'adressage peu orthodoxes dans l'espoir de trouver des données de test unitaire, mais de manière inquiétante, je n'ai trouvé aucun résultat dans tout le référentiel.
Je pense que votre meilleur pari est de traiter une adresse comme un texte multiligne de forme libre. Il est nul que vous ne puissiez pas valider toutes les adresses, mais certains formats d'adressage sont vraiment étranges et peut-être imprévus et, en fin de compte, la responsabilité de remplir la bonne adresse incombe à l'utilisateur et dans la plupart des applications, l'utilisateur supporte les conséquences négatives du remplissage d'un adresse invalide.
Vous pourriez, peut-être, utiliser un validateur pour fournir un avertissement, mais rien de plus. Mais ne rejetez pas les adresses qui ne valident pas, sinon vous risquez de perdre des clients. Ce qui conduit à la question de savoir comment communiquer l'avertissement à l'utilisateur de telle manière qu'il communiquera que, si l'utilisateur vit dans une zone avec un format d'adresse étrange, il est sûr d'ignorer l'avertissement ...