Étant donné la tâche consistant à stocker des adresses géographiques internationales dans une table relationnelle, quel est le schéma le plus flexible ? Chaque partie de l'adresse doit-elle être répartie dans ses propres champs, ou doit-elle s'apparenter à du texte libre ?
Est-il utile de séparer les adresses de format différent dans des tables différentes ? Par exemple, avoir une table pour USAAddress, CanadianAddress, UKAddress... ?
Je vais résumer mes pensées à partir de mon article de blog -. Une leçon de stockage d'adresses (sur archive.org).
Dans mon projet actuel [je travaille pour une entreprise de logistique], nous stockons des adresses internationales. J'ai fait des recherches sur les adresses du monde entier pour concevoir cette partie de la base de données. Il y a beaucoup de formats différents. Dans le monde occidental, nous avons tendance à utiliser un format assez uniforme - quelques différences, mais elles sont pour la plupart :
Cela semble couvrir la plupart des pays, mais l'ordre des champs peut être affiché différemment. Vous trouverez une liste des formats d'affichage à l'adresse suivante http://www.bitboost.com/ref/international-address-formats.html#Formats
Par exemple, dans de nombreux pays, le code postal précède le nom de la ville et le numéro de la rue suit le nom de la rue. Au Canada, aux États-Unis et au Royaume-Uni, le numéro de la rue précède le nom de la rue et le code postal (ou ZIP) vient après le nom de la ville.
Pour répondre à votre question sur la séparation des adresses en différents pays, je ne le suggérerais pas, cela ne ferait que rendre la vie plus difficile dans d'autres domaines, par exemple pour les rapports. Le format que j'ai fourni couvre toutes les adresses de notre base de données logistique, qui couvre les États-Unis, le Canada, le Mexique et le Royaume-Uni sans aucun problème. Il couvre également toutes nos adresses européennes, chinoises, japonaises et malaisiennes. Je ne peux pas parler pour les autres pays, mais je n'ai pas encore eu à stocker une adresse d'un pays que ces champs ne prennent pas en charge.
Je ne suggère pas d'utiliser le format Adresse1, Adresse2, Adresse3 suggéré par d'autres et que l'on retrouve dans de nombreuses bases de données, car l'analyse des informations relatives à l'adresse à partir d'une chaîne alphanumérique n'est pas aussi simple qu'il n'y paraît, surtout si les données ne sont pas saisies correctement, en raison d'informations erronées, de fautes de frappe, de fautes d'orthographe, etc. Si vous séparez vos champs, vous pouvez utiliser des algorithmes de distance pour vérifier la signification probable, utiliser la probabilité pour vérifier le nom de la rue par rapport au code postal et au numéro de rue ou pour vérifier la province et la ville par rapport au nom de la rue, etc. Essayez de faire tout cela lorsque vous avez une chaîne de caractères indiquant l'adresse complète de votre rue. Il ne s'agit pas d'un problème trivial, loin s'en faut.
L'assurance qualité sur une base de données d'adresses est un casse-tête, point final. Le moyen le plus simple de vous simplifier la vie dans ce domaine est de vous assurer que tous les champs ne contiennent qu'un seul élément d'information dont l'exactitude peut être vérifiée automatiquement au moment de la saisie. Les probabilités, les algorithmes de distance et les expressions régulières peuvent vérifier la validité de l'entrée et fournir à l'utilisateur un retour d'information sur son erreur et suggérer des corrections appropriées.
Il faut faire attention aux routes dont le nom est également un type de rue - si vous couvrez le Canada, vous devez être conscient de l'existence de "Avenue Road" à Toronto, qui vous fera perdre beaucoup de temps si vous utilisez le format Address1, 2, 3. Il est probable que cela se produise dans d'autres endroits également, bien que je n'en aie pas connaissance - ce seul cas a suffi pour que je crie "WTF !
Thomas - Beaucoup, beaucoup de recherches et de listes. Australie, Royaume-Uni, Irlande, Canada, États-Unis, îles Anglo-Normandes, France. C'était une tâche ardue sans obtenir la base de données postale de chaque pays.
Thomas - N'oubliez pas que dans les parties anglophones du monde, nous volons souvent des noms d'autres pays - par exemple, les États-Unis utilisent des noms espagnols dans de nombreux endroits et le Canada utilise aussi des noms français.
Veillez à ne pas trop analyser les formats d'adresse. Si vous le faites, vous risquez fort de vous retrouver avec une spécification dont la plupart des utilisateurs auront besoin pour travailler autour de ce qui les oblige effectivement à utiliser les mauvais champs, ou à ne remplir que les champs primaires et à ignorer les champs supplémentaires.
Gardez les choses simples.
Un StreetType comme celui mentionné par BenAlabaster posera des problèmes lorsque vous commencerez à travailler avec des langues différentes des langues isolées comme l'anglais ou l'espagnol.
Pour vous montrer à quel point les choses peuvent mal tourner dans la nature : la "Henriette Roland Holststraat" à Amsterdam, construite à partir de "Henriette" + "Roland Holst" + "straat", qui peut être abrégée en "Roland Holststraat", ou "Roland Holststr.", ou mal orthographiée en "H.R.Holststr." ou "Henriette Roland-Holst straat", selon le temps. Si vous ne disposez pas d'un registre des rues à jour pour chaque pays du monde, vous n'arriverez à rien.
Et enfin, faites attention que dans certains pays multilingues, les noms peuvent être différents d'une langue à l'autre ! Par exemple à Bruxelles, où de nombreuses rues ont à la fois un nom français et un nom anglais. et un nom néerlandais : "Avenu du Port" et "Havenlaan", selon la langue préférée du destinataire. (Google Maps indique alternativement les deux noms, par précaution).
Vous pouvez essayer d'imaginer toutes sortes de trucs astucieux, mais les représentants commerciaux vont-ils comprendre ?
Cela dépend de ce que vous voulez en faire.
J'ai constaté qu'il est toujours plus facile d'utiliser les adresses à d'autres fins (comme la vérification par rapport aux données de l'USPS ou l'obtention des tarifs d'expédition d'UPS/FEDEX) si elles sont séparées.
Voici ce que j'utilise généralement pour les adresses :
En réponse à l'édition : Dans la plupart des cas, je n'en vois pas l'utilité. La table que j'ai listée ci-dessus a assez de champs (et est assez générique) pour les adresses de la plupart des pays.
Les lignes d'adresse 1, 2 et 3 sont suffisamment génériques, mais lorsqu'il s'agit d'analyser les adresses de manière programmatique, vous vous retrouvez dans une impasse. L'analyse programmatique des adresses n'est pas une tâche triviale si l'on considère les formats d'adresses internationaux.
À l'opposé de l'excellente réponse fournie par @BenAlabaster, vous pourriez simplement avoir.. :
address TEXT(300)
postal_code VARCHAR(15)
country_code VARCHAR(2)La mise en page de vos formulaires côté client peut être aussi complexe que vous le souhaitez (ou utiliser une entrée multiligne où l'utilisateur peut taper manuellement son adresse). Vous pouvez ensuite ajouter les sauts de ligne dans l'adresse si nécessaire.
Votre table de campagne aurait l'aspect suivant :
country_code VARCHAR(2)
country_name VARCHAR(255)En outre, vous pourriez avoir un des éléments suivants :
postal_code_required TINYINT(1)
postal_code_regex VARCHAR(255) NULL DEFAULT NULLUtilisez ensuite les listes suivantes pour concevoir votre table de pays :
Le seul moyen est de les diviser pour :
Name varchar,
Title varchar,
StreetAddress varchar,
StreetAddressLine2 varchar,
zipCode varchar,
City varchar,
Province varchar,
Country lookuppuisque presque tous les pays ont leur propre norme pour les données d'adresse, et que chaque pays a un format différent de code postal.
Vous pouvez avoir un petit échantillon de problèmes dans mon poste d'une question similaire.
Il n'est pas nécessaire de séparer les adresses pour chaque pays, car il existe des pays où les conventions d'adresse sont rares. Certaines conventions populaires incluent le fait de ne pas avoir de rues dans les petits villages, seulement le nom et le numéro du village, alors que les rues sont dans les adresses des grandes villes. J'ai appris que dans la capitale hongroise - Budapest, il y a peu de rues ayant le même nom (on les distingue par le numéro du district de la ville), alors que d'autres villes n'ont pas de telles adresses (quelqu'un de Hongrie peut confirmer si c'est vrai). Donc le nombre total de formats d'adresses sera numer_of_countries multiplié par le nombre de formats d'adresses dans ce pays Cela peut être fait avec différentes tables, mais ce sera un travail horrible à faire.
Comment se fait-il que vous ayez utilisé Province sauf ZipCode ? De plus, StreetAddress et StreetAddressLine2 sont suffisamment génériques pour être affichés, mais si vous devez faire de l'EDI ou analyser les adresses de manière programmatique pour l'assurance qualité (ou pour toute autre raison), vous allez vous retrouver dans un arbre à gomme.
Cela dépend simplement de la raison pour laquelle vous avez besoin de ces données. Pour l'envoi de courrier à des clients dans le monde entier, ma solution sera correcte. Pour l'EDI mondial, vous aurez probablement besoin de quelque chose comme votre réponse à cette question. Toutefois, à des fins de navigation, vous aurez besoin de structures de données supplémentaires contenant des données SIG et des liens entre elles (ainsi, vous saurez que l'adresse 1 est située au même endroit que l'adresse 2, même si elles ont un nom de rue différent, etc.) Il est donc difficile de dire quelle solution est la bonne (pas trop compliquée et suffisamment précise) sans connaître le contexte.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
schema.org/PostalAddress - utilisé par les moteurs de recherche comme standard