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

Question

Je suis un programmeur et j'ai besoin d'une approche pratique pour stocker les structures d'adresses de rue du monde dans une base de données. Quelle est donc la conception de base de données la meilleure et la plus courante pour stocker des adresses de rue ? Elle doit être simple à utiliser, rapide à interroger et dynamique pour stocker toutes les adresses du monde.

Answer 1

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 voie d'accès nommée (artère) 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 : le nom de l'établissement (ville/ville/village), qui peut être désigné sous le nom générique de localité ; le nom de la région et l'attribution d'un code postal alphanumérique. Notez que les codes postaux, également appelés 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 (UPU) fournit des données d'adresses pour de nombreux pays dans une format standard . Notez que le format UPU contient toutes les adresses (jusqu'à la précision du champ disponible) pour un pays entier, il est donc relationnel. Si vous stockez des adresses de 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 un format plat) contenant tous les champs et une adresse par ligne.

Un format raisonnable pour le stockage des adresses serait le suivant :

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

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

• Bâtiment
• Sous-bâtiment
• Numéro du local (numéro de la maison)
• Gamme de locaux
• Voie de circulation
• Sous-arrondissement
• Localité à double dépendance
• Sous-localité

Souvent, seules 3 lignes d'adresse sont utilisées, mais c'est souvent insuffisant. Il est bien sûr possible d'exiger davantage de lignes pour représenter toutes les adresses au format officiel, mais les virgules peuvent toujours être utilisées comme séparateurs de ligne, ce qui signifie que les informations peuvent toujours être saisies.

Habituellement, l'analyse des données est 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. Toutefois, ne forcez pas les utilisateurs à fournir le code postal ou la région, car ils ne sont peut-être pas utilisés localement.

La localité peut être peu claire, notamment la distinction entre la localité cartographique et la localité postale. La localité postale est celle considérée par une autorité postale qui peut parfois être une grande ville proche. Toutefois, le code postal résout généralement tout problème ou toute divergence à ce niveau, afin de permettre une livraison correcte même si la localité postale officielle n'est pas utilisée.

Answer 2

Jetez un coup d'œil à Réponses de la base de données . Concrètement, 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

Answer 3

Demandez-vous quel est le principal objectif de stocker ces données ? Avez-vous l'intention d'envoyer réellement du courrier à la personne dont l'adresse est indiquée ? Suivre les données démographiques, les populations ? Pouvoir demander aux appelants leur adresse exacte dans le cadre d'une authentification/vérification de base ? Toutes ces réponses ? Aucune de ces réponses ?

En fonction de votre besoin réel, vous déterminerez soit a) que cela n'a pas vraiment d'importance et que vous pouvez opter pour une approche en texte libre, soit b) des champs structurés/spécifiques pour tous les pays, soit c) une architecture spécifique à chaque pays.

Answer 4

Parfois, l'adresse la plus proche de la rue est la ville.

J'ai eu un jour le projet de placer toutes les écoles secondaires de l'Inde sur Google Maps. J'ai écrit un beau programme en utilisant l'API de Google et je pensais que ce serait assez facile.

Puis j'ai reçu les données du client. Certaines adresses d'écoles étaient des choses comme "En face du marché, à côté du coiffeur" ou "Près de l'ancienne station de bus".

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

Answer 5

Pour les adresses internationales, il est remarquablement 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>

Par exemple

Via Eroi della Repubblica
89861 Tropea VV
Italy

C'est assez différent de la commande pour les adresses américaines - sur la deuxième ligne.

Voir aussi les questions de l'OS :

• Combien de champs d'adresse utiliseriez-vous pour une base de données britannique ?
• Est-ce que vous décomposez les adresses en rue / ville / état / code postal ?
• Comment traitez-vous les suffixes de rue en double ?
• Meilleures pratiques pour le stockage des adresses postales dans une base de données (SGBDR) ?

Consultez également le tag ' code postal '.

---

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