Je suis un programmeur et pour être honnête, je ne connais pas la structure des adresses du monde, mais comment mon pays est structuré :). Quelle est donc la meilleure et la plus courante des bases de données pour stocker les adresses? Il devrait être si simple à utiliser, rapide à interroger et dynamique pour stocker toutes les adresses civiques du monde identifiant par un seul identifiant
Merci beaucoup
Il est possible de représenter des adresses de nombreux pays différents dans un ensemble de champs standard. L'idée de base d'une voie d'accès nommée (voie de circulation) sur laquelle les bâtiments nommés ou numérotés sont situés est assez standard, sauf parfois en Chine. Parmi les autres concepts quasi universels, citons: la désignation de la localité (ville/village/village), que l’on peut généralement appeler une localité; nommer la région et attribuer un code postal alphanumérique. Notez que les codes postaux, également appelés codes postaux, sont purement numériques uniquement dans certains pays. Vous aurez besoin de beaucoup de champs si vous voulez vraiment être générique.
L'Union postale universelle de l'UPU fournit des données sur les adresses de nombreux pays au format format standard . Notez que le format UPU contient toutes les adresses (jusqu’à la précision du champ disponible) pour tout un pays, il est donc relationnel. Si vous stockez des adresses de clients, où ne sera stockée qu’une petite fraction de toutes les adresses possibles, il est préférable d’utiliser une seule table (ou un format plat) contenant tous les champs et une adresse par ligne.
Un format raisonnable pour stocker les adresses serait le suivant:
Les lignes d’adresse 1 à 4 peuvent contenir des composants tels que:
Souvent, seules 3 lignes d'adresse sont utilisées, mais cela est souvent insuffisant. Il est bien sûr possible d'exiger plus de lignes pour représenter toutes les adresses dans le format officiel, mais les virgules peuvent toujours être utilisées comme séparateurs de ligne, ce qui signifie que les informations peuvent toujours être capturées.
Habituellement, l'analyse des données serait effectuée par localité, région, code postal et pays, et ces éléments sont assez faciles à comprendre pour les utilisateurs lors de la saisie de données. C'est pourquoi ces éléments doivent être stockés sous forme de champs séparés. Cependant, ne forcez pas les utilisateurs à fournir un code postal ou une région, ils ne peuvent pas être utilisés localement.
La localité peut ne pas être claire, en particulier la distinction entre la localité de la carte et la localité postale. La localité postale est celle jugée par une autorité postale qui peut parfois être une grande ville voisine. Cependant, le code postal résoudra généralement tous les problèmes ou incohérences afin de permettre une livraison correcte, même si la destination officielle n'est pas utilisée.
Jetez un oeil à réponses de base de données . Plus précisément, cela couvre de nombreux cas:
(Tous types de données de longueur variable)
AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails
Demandez-vous quel est le principal but de stocker ces données? Avez-vous l'intention d'envoyer un courrier à la personne à l'adresse? Suivre les données démographiques, les populations? Être capable de demander aux appelants leur adresse correcte dans le cadre d'une authentification/vérification de base? Tout ce qui précède? Aucune de ces réponses?
En fonction de vos besoins réels, vous déterminerez soit a) cela ne compte pas vraiment, et vous pouvez opter pour une approche en texte libre, ou b) des champs structurés/spécifiques pour tous les pays, ou c) une architecture spécifique à chaque pays.
Parfois, le plus proche, vous pouvez obtenir une adresse est la ville.
Un jour, j’ai eu l’idée de mettre toutes les écoles secondaires de l’Inde dans Google Maps. J'ai écrit un programme épatant à l'aide de l'API Google et j'ai pensé que ce serait très facile.
Ensuite, j'ai eu les données du client. Certaines adresses d'école étaient des choses telles que "En face du marché, à côté du barbier" ou "Près du vieil arrêt de bus".
Cela a rendu ma tâche beaucoup plus difficile car, malheureusement, l'API de Google ne prend pas en charge ce format.
Pour les adresses internationales, il est extrêmement difficile de trouver un moyen de formater l’information si elle est décomposée en champs. Par exemple, une adresse italienne utilise:
<street address>
<Zip> <town> <region>
<country>
Tel que
Via Eroi della Repubblica
89861 Tropea VV
Italy
C'est assez différent de l'ordre pour les adresses américaines - sur la deuxième ligne.
Voir aussi les SO questions:
Consultez également la balise ' code postal '.
Edit : Ordre inverse de la région et de la ville - par UPU
Peut-être que cela est utile: https://Gist.github.com/259744 Pour un projet, j'ai rassemblé un tableau d'informations sur tous les pays du monde, y compris les codes ISO, le domaine de premier niveau, le code de téléphone, signe de voiture, longueur et regex de Zip. Noms de pays et commentaires malheureusement uniquement en allemand ...
Non, il n'y a pas de schéma d'adressage standard. Cela varie généralement d'un pays à l'autre. Même l'Union postale universelle a dit le S'adressant au monde, une adresse pour tout le monde qu'il n'y en a pas. Pour ce faire, la meilleure solution consiste à utiliser les normes de codes de pays de 2/3 lettres connues sous le nom de ISO 3166 et à traiter le reste selon les normes du pays.
Toutefois, si vous souhaitez réellement utiliser des outils facilement accessibles pour votre projet, vous pouvez essayer API Google Place .
Non, absolument pas. Si vous comparez le fonctionnement des États-Unis et du adresses japonaises , vous constaterez que ce n'est pas possible.
MISE À JOUR:
À la réflexion, tout peut être fait, mais il y a un compromis.
Une approche consiste à modéliser le problème avec les tables address et address_attribute, avec une relation 1: m entre elles, tout peut être modélisé. La table address_attribute aurait un pk, un nom, une valeur et un fk qui pointe vers le pk de son adresse mère. C'est presque comme utiliser une carte avec un nom, des paires de valeurs.
Le compromis est de faire un JOIN chaque fois que vous voulez une adresse. Vous devez également interroger les noms de l'adresse_attributs pour comprendre à quoi vous avez affaire à chaque fois.
Une autre approche consisterait à effectuer des recherches plus complètes sur la manière dont les adresses sont modélisées dans le monde entier. Dans un monde orienté objet, vous pouvez avoir la classe d’adresses occidentale (street1/street2/city/state/Zip) et d’autres pour le Japon, la Chine, autant que de besoin pour créer l’espace adresse en mosaïque. Vous obtenez ensuite une table d'adresses principale et des tables enfants associées aux autres types avec une relation 1: 1 entre eux.
Comment Amazon ou eBay le fait-il? Ils expédient à l'international. Ont-ils des fonctionnalités d'interface utilisateur spécifiques aux paramètres régionaux? J'ai seulement utilisé les paramètres régionaux américains.
Cela dépend de la façon dont vous êtes prêt à aller avec les champs. Un champ d'adresse libre suffira évidemment, mais vous aidera relativement peu à réduire la géographie.
Le problème que vous aurez, c'est qu'il y a trop de variations dans le niveau de hiérarchie géographique entre les pays. Heck, certains pays n'ont même pas d '"adresses de rue" partout.
Je vous recommande de ne pas essayer de le rendre trop intelligent.
À la différence d'autres réponses ici, je pense qu'il est possible d'avoir une base de données d'adresses structurée.
En sortant du chapeau, je peux penser à la structure suivante:
Mais comment l'interroger assez vite?
Je pense toujours que cela peut être accompli en demandant le code postal (ou code postal) qui varie d’un pays à l’autre, mais qui est solide dans le pays.
De cette façon, vous pouvez structurer vos données autour des informations fournies par les bureaux de poste du monde entier.
Len Silverston de niversal Data Model fame recommande une hiérarchie distincte de GEOGRAPHIC BOUNDARIES
Et en fonction du degré de libre-forme que vous êtes prêt à accepter, soit de simples STREET ADDRESS LINE
S ou dérivés par pays.
Votre conception doit dépendre fortement de votre objectif. Certaines personnes ont posté comment structurer les données. Donc, si vous voulez simplement envoyer du courrier électronique à quelqu'un, ça ira. Les choses commencent à se compliquer si vous souhaitez utiliser ces données pour la navigation. La navigation en voiture nécessitera des structures supplémentaires pour contenir les informations de trafic (par exemple, des routes à sens unique), tandis que la navigation à pied nécessitera beaucoup de données supplémentaires. Voici un petit exemple: dans ma ville, mon quartier est proche du parc. À côté du parc se trouve l'ancien aérodrome (l'un des plus anciens d'Europe), transformé en musée de l'aviation. A côté du musée de l'aviation se trouve un parc d'activités. Le numéro de rue du musée est 39%, alors que le numéro du parc d'activité commence par 39A. Donc, il peut sembler que 39 et 39A sont proches - mais cela prend environ un mile pour aller de l'un à l'autre (et même plus longtemps si vous y allez en voiture).
Ceci est juste un petit exemple tiré de ma ville, je pense que vous pouvez probablement trouver beaucoup d’exceptions (en particulier dans les régions rurales ou plus sauvages de tous les pays).