Meilleures pratiques pour stocker les adresses postales dans une base de données (SGBDR)?

Existe-t-il de bonnes références pour les meilleures pratiques de stockage des adresses postales dans un SGBDR? Il semble qu'il y ait beaucoup de compromis à faire et de nombreux avantages et inconvénients à évaluer pour chacun - cela a sûrement été fait maintes et maintes fois? Peut-être que quelqu'un a au moins écrit des leçons apprises quelque part?

Des exemples de compromis dont je parle sont le stockage du code postal sous forme d'entier par rapport à un champ de caractères, si le numéro de maison est stocké comme un champ séparé ou une partie de la ligne d'adresse 1, si les numéros de suite / appartement / etc doivent être normalisés ou simplement stockés sous forme de morceau de texte dans la ligne d'adresse 2, comment gérez-vous zip +4 (champs séparés ou un grand champ, entier vs texte)? etc.

Je suis principalement préoccupé par les adresses américaines à ce stade, mais j'imagine qu'il existe certaines meilleures pratiques pour vous préparer à l'éventualité de devenir mondial également (par exemple, nommer les champs de manière appropriée comme la région au lieu de l'état ou le code postal au lieu du code postal, etc.

Pour une utilisation plus internationale, un schéma à considérer est celui utilisé par Drupal Address Field . Il est basé sur la norme xNAL et semble couvrir la plupart des cas internationaux. Un peu de fouille dans ce module révélera de belles perles pour interpréter et valider les adresses à l'international. Il a également un bel ensemble de zones administratives (province, état, oblast, etc.) avec des codes ISO.

Voici l'essentiel du schéma, copié à partir de la page du module:

country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)

Une des leçons que j'ai apprises:

• Ne stockez rien numériquement.
• Enregistrez le pays et la zone administrative sous forme de codes ISO si possible.
• Lorsque vous ne savez pas, soyez laxiste sur les champs obligatoires. Certains pays peuvent ne pas utiliser des champs que vous tenez pour acquis, même des éléments de base comme locality& thoroughfare.

En tant qu'utilisateur «international», il n'y a rien de plus frustrant que de traiter avec un site Web orienté uniquement vers des adresses au format américain. C'est un peu impoli au début, mais devient un problème sérieux lorsque la validation est également trop zélée.

Si vous souhaitez devenir mondial, le seul conseil que j'ai est de garder les choses libres. Différents pays ont des conventions différentes - dans certains, le numéro de la maison vient avant le nom de la rue, dans certains il vient après. Certains ont des États, certaines régions, certains comtés, certaines combinaisons de ceux-ci. Ici au Royaume-Uni, le code postal n'est pas un code postal, c'est un code postal contenant à la fois des lettres et des chiffres.

Je conseillerais simplement ~ 10 lignes de chaînes de longueur variable, avec un champ séparé pour un code postal (et faites attention à la façon dont vous le décrivez pour faire face aux sensibilités nationales). Laisser l'utilisateur / client décider comment écrire ses adresses.

Si vous avez besoin d'informations complètes sur la manière dont les autres pays utilisent les adresses postales, voici un très bon lien de référence (Columbia University):

Guide contraignant de Frank sur les adresses postales
Adressage efficace pour le courrier international

Vous devriez certainement envisager de stocker le numéro de la maison sous forme de champ de caractères plutôt que de nombre, en raison de cas particuliers tels que "demi-nombres", ou mon adresse actuelle, qui est quelque chose comme "129A" ​​- mais le A n'est pas considéré comme un appartement numéro pour les services de livraison.

Je l'ai fait (modéliser rigoureusement les structures d'adresses dans une base de données), et je ne le referais plus jamais. Vous ne pouvez pas imaginer à quel point les exceptions sont folles que vous devrez prendre en compte en règle générale.

Je me souviens vaguement d'un problème avec les codes postaux norvégiens (je pense), qui étaient tous les 4 positions, sauf Oslo, qui en avait 18 environ.

Je suis convaincu qu'à partir du moment où nous avons commencé à utiliser les codes postaux géographiquement corrects pour toutes nos propres adresses nationales, un bon nombre de personnes ont commencé à se plaindre que leur courrier arrivait trop tard. Il s'est avéré que ces personnes vivaient près d'une frontière entre les zones postales, et malgré le fait que quelqu'un vivait vraiment dans la zone postale, disons 1600, en réalité, son courrier devrait être adressé à la zone postale 1610, car en réalité c'était cette zone postale voisine. qui le servait réellement, donc envoyer son courrier à sa bonne zone postale prendrait quelques jours de plus pour arriver à ce courrier, en raison de l'intervention indésirable qui était nécessaire dans le bon bureau de poste pour le transmettre à la mauvaise zone postale ...

(Nous avons fini par enregistrer ces personnes avec une adresse à l'étranger dans le pays avec le code ISO `` ZZ ''.)

Vous devriez certainement consulter " Est-ce un bon moyen de modéliser les informations d'adresse dans une base de données relationnelle ", mais votre question n'en est pas une copie directe.

Il y a sûrement beaucoup de réponses préexistantes (consultez les exemples de modèles de données sur DatabaseAnswers , par exemple). Bon nombre des réponses préexistantes sont défectueuses dans certaines circonstances (pas du tout de sélection sur DB Answers).

Un problème majeur à considérer est la portée des adresses. Si votre base de données doit traiter des adresses internationales, vous devez être plus flexible que si vous ne devez traiter que des adresses dans un seul pays.

À mon avis, il est souvent (ce qui ne veut pas dire toujours ) judicieux à la fois d'enregistrer «l'image d'étiquette d'adresse» de l'adresse et d'analyser séparément le contenu. Cela vous permet de gérer les différences entre le placement des codes postaux, par exemple, entre différents pays. Bien sûr, vous pouvez écrire un analyseur et un formateur qui gèrent les excentricités de différents pays (par exemple, les adresses américaines ont 2 ou 3 lignes; en revanche, les adresses britanniques peuvent en avoir beaucoup plus; une adresse à laquelle j'écris périodiquement a 9 lignes). Mais il peut être plus facile de demander aux humains de faire l'analyse et le formatage et de laisser le SGBD stocker simplement les données.

À moins que vous ne fassiez des calculs sur les numéros de rue ou les codes postaux / postaux, vous invitez simplement à la douleur future en les stockant sous forme de chiffres.

Vous pourriez économiser quelques octets ici et là, et peut-être obtenir un index plus rapide, mais que faites-vous lorsque la poste américaine, ou tout autre pays avec lequel vous traitez, décide d'introduire des alphas dans les codes?

Le coût de l'espace disque sera beaucoup moins cher que le coût de sa réparation plus tard ... y2k quelqu'un?

En plus de ce que @ Jonathan Leffler et @ Paul Fisher ont dit

Si jamais vous prévoyez d'ajouter des adresses postales pour le Canada ou le Mexique à vos besoins, le stockage postal-codesous forme de chaîne est un must. Le Canada a des codes postaux alphanumériques et je ne me souviens pas de ce à quoi ressemble le Mexique.

J'ai trouvé que lister tous les champs possibles, de la plus petite unité discrète au plus grand, est le moyen le plus simple. Les utilisateurs rempliront les champs qui leur conviennent. Ma table d'adresses ressemble à ceci:

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

Où est le "compromis" dans le stockage du ZIP sous forme de NUMBER ou VARCHAR? C'est juste un choix - ce n'est pas un compromis à moins qu'il y ait des avantages pour les deux et que vous deviez renoncer à certains avantages pour en obtenir d'autres.

À moins que la somme des zips n'ait de sens, les zips en tant que nombre ne sont pas utiles.

Cela peut être excessif, mais si vous avez besoin d'une solution qui fonctionnerait avec plusieurs pays et que vous devez traiter par programme des parties de l'adresse:

vous pouvez avoir une gestion des adresses spécifiques au pays à l'aide de deux tables: une table générique avec 10 colonnes VARCHAR2, 10 colonnes Number, une autre table qui mappe ces champs à des invites et a une colonne country liant une structure d'adresse à un pays.

Si jamais vous devez vérifier une adresse ou l'utiliser pour traiter des paiements par carte de crédit, vous aurez au moins besoin d'une petite structure. Un bloc de texte de forme libre ne fonctionne pas très bien pour cela.

Le code postal est un champ facultatif courant pour valider les transactions par carte de paiement sans utiliser l'adresse complète. Ayez donc un champ séparé et généreusement dimensionné pour cela (au moins 10 caractères).

Inspiré des réponses de base de données

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Je voudrais simplement mettre tous les champs ensemble dans un grand champ NVARCHAR (1000), avec un élément textarea pour que l'utilisateur entre la valeur (à moins que vous ne souhaitiez effectuer une analyse sur, par exemple, les codes postaux). Toutes ces entrées de ligne d'adresse 1, ligne d'adresse 2, etc. sont tellement ennuyeuses si vous avez une adresse qui ne correspond pas bien à ce format (et, vous savez, il y a d'autres pays que les États-Unis).