Existe-t-il une conception de base de données commune d'adresses de rue pour toutes les adresses du monde?

Je suis un programmeur et, pour être honnête, je ne connais pas les structures d'adresses publiques du monde, mais comment mon pays est structuré :) alors quelle est la meilleure conception de base de données commune pour stocker les adresses municipales? Cela devrait être si simple à utiliser, rapide à interroger et dynamique pour stocker toutes les adresses de rue du monde qui s'identifient juste par un identifiant
Merci beaucoup

Il est possible de représenter des adresses de nombreux pays différents dans un ensemble standard de champs. L'idée de base d'une route d'accès nommée (artère) sur laquelle se trouvent les bâtiments nommés ou numérotés est assez standard, sauf parfois en Chine. D'autres concepts quasi universels comprennent: la dénomination de la colonie (ville / village / village), qui peut être désignée de manière générique comme une localité; nommer la région et attribuer un code postal alphanumérique. Notez que les codes postaux, également connus sous le nom de codes postaux, ne sont purement numériques que 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 les adresses de nombreux pays dans un format standard . Notez que le format UPU contient toutes les adresses (jusqu'à la précision de champ disponible) pour tout un pays, il est donc relationnel. Si vous stockez les adresses des clients, où seule une petite fraction de toutes les adresses possibles sera stockée, il est préférable d'utiliser une seule table (ou format plat) contenant tous les champs et une adresse par ligne.

Un format raisonnable pour stocker les adresses serait le suivant:

• Lignes d'adresse 1 à 4
• Localité
• Région
• Code postal (ou code postal)
• Pays

Les lignes d'adresse 1 à 4 peuvent contenir des composants tels que:

• Bâtiment
• Sous-bâtiment
• Numéro de local (numéro de maison)
• Gamme Premise
• Rue
• Sous-voie ferrée
• Localité à double dépendance
• Sous-localité

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.

En général, 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 des données. C'est pourquoi ces éléments doivent être stockés dans des 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 être floue, en particulier la distinction entre la localité cartographique 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 les problèmes ou les écarts, pour permettre une livraison correcte même si la poste-localité officielle n'est pas utilisée.

Jetez un œil à Database Answers . Plus précisément, cela couvre de nombreux cas:

(Tous les types de données de caractères de longueur variable)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Demandez-vous quel est l' objectif principal du stockage de ces données? Avez-vous l'intention d'envoyer du courrier à la personne à l'adresse? Suivre les données démographiques, les populations? Pouvoir 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 n'a pas vraiment d'importance 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 au pays.

Parfois, le plus proche d'une adresse postale est la ville.

Une fois, j'ai eu un projet pour mettre toutes les écoles secondaires en Inde dans Google Maps. J'ai écrit un programme amusant en utilisant l'API Google et j'ai pensé que ce serait assez simple.

Ensuite, j'ai obtenu les données du client. Certaines adresses d'école étaient des choses comme "En face du marché, à côté du barbier" ou "Près d'un ancien arrêt de bus".

Cela a rendu ma tâche beaucoup plus difficile car, malheureusement, l'API Google ne prend pas en charge ce format.

Pour les adresses internationales, il est extrêmement difficile de trouver un moyen de formater les informations si elles sont décomposées 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 des adresses américaines - sur la deuxième ligne.

Voir aussi les questions SO:

• Combien de champs d'adresse utiliseriez-vous pour une base de données britannique?
• Divisez-vous les adresses en rue / ville / état / code postal?
• Comment gérez-vous les suffixes de rue en double?
• Meilleures pratiques pour stocker les adresses postales dans une base de données (SGBDR)?

Consultez également l'étiquette « code postal ».

Edit : Ordre inverse de la région et de la ville - par UPU

Peut-être que c'est utile: https://gist.github.com/259744 Pour un projet, j'ai rassemblé une table d'informations sur tous les pays du monde, y compris les codes ISO, le domaine de premier niveau, le code de téléphone, le signe de la voiture, la longueur et l'expression régulière de Zip *: français. Noms de pays et commentaires malheureusement uniquement en allemand ...

Cela dépend de la forme libre avec laquelle vous êtes prêt à utiliser les champs. Un champ d'adresse de forme libre fera évidemment toujours l'affaire, mais sera relativement peu utile pour réduire la géographie.

Le problème que vous aurez est qu'il y a trop de variation dans le niveau de hiérarchie géographique entre les pays. Heck, certains pays n'ont même pas des «adresses» partout.

Je vous recommande de ne pas essayer de le rendre trop intelligent.

Contrairement aux autres réponses ici, je pense qu'il est possible d'avoir une base de données d'adresses structurée.

À peine sorti du chapeau, je peux penser à la structure suivante:

• Pays
• Région (État / Province)
• Localité (ville / municipalité)
• Sous-localité (comté / autre sous-division d'une localité)
• rue

Mais comment l'interroger assez rapidement?

Une façon dont je pense toujours que cela peut être accompli est de demander le code postal (ou code postal) qui varie d'un pays à l'autre, mais qui est solide à l'intérieur du 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 la renommée Universal Data Model recommande une hiérarchie distincte de GEOGRAPHIC BOUNDARIESet en fonction du degré de forme libre que vous êtes prêt à accepter soit des STREET ADDRESS LINEdérivés simples, soit des dérivés par pays.

Non, absolument pas. Si vous comparez le fonctionnement des adresses américaines et japonaises , vous verrez que ce n'est pas possible.

METTRE À JOUR:

À la réflexion, tout peut être fait, mais il y a un compromis.

Une approche consiste à modéliser le problème avec des 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 parent d'adresse. C'est presque comme utiliser une carte avec un nom, des paires de valeurs.

Le compromis est d'avoir à faire un JOIN à chaque fois que vous voulez une adresse. Vous devez également interroger les noms des adresses_attributs pour savoir à quoi vous avez affaire à chaque fois.

Une autre approche consisterait à effectuer une recherche plus approfondie sur la manière dont les adresses sont modélisées dans le monde. Dans un monde orienté objet, vous pouvez avoir la classe d'adresse occidentale (rue1 / rue2 / ville / état / zip) et d'autres pour le Japon, la Chine, autant que nécessaire pour carreler l'espace d'adressage. Ensuite, vous auriez une table d'adresses principale et des tables enfants pour les autres types avec une relation 1: 1 entre elles.

Comment fait Amazon ou eBay? Ils expédient à l'international. Ont-ils des fonctionnalités d'interface utilisateur spécifiques aux paramètres régionaux? Je n'ai utilisé que les paramètres régionaux américains.

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 déclaré sur Adresser le monde, une adresse pour tous qu'il n'y en a pas. La meilleure solution pour cela est d'utiliser les normes de code de pays 2/3 lettres connues sous le nom d' ISO 3166 et de traiter tout le reste selon les normes du pays.

Cependant, si vous avez vraiment envie d'utiliser des outils facilement accessibles pour votre projet, vous pouvez essayer l' API Google Place .

Votre conception doit fortement dépendre de votre objectif. Certaines personnes ont posté comment structurer les données. Donc, si vous voulez simplement envoyer un s-mail à quelqu'un, cela fera l'affaire. Les choses commencent à se compliquer si vous souhaitez utiliser ces données pour la navigation. La navigation automobile nécessitera des structures supplémentaires pour contenir des informations sur le trafic (par exemple, les 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. A côté du parc se trouve un ancien aérodrome (en fait, l'un des plus anciens d'Europe) transformé en musée de l'aviation. À côté du musée de l'aviation se trouve un parc d'affaires. Le numéro de rue du musée est le 39, tandis que les numéros de parc d'affaires commencent par 39A. Il peut donc sembler que 39 et 39A sont proches - mais il faut environ un kilomètre pour marcher de l'un à l'autre (et même plus si vous allez en voiture).
Ceci est juste un petit exemple pris dans ma ville, je pense que vous pouvez probablement trouver beaucoup d'exceptions (en particulier dans les régions rurales ou plus sauvages de chaque pays).