Meilleures pratiques pour le stockage des 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 beaucoup d'avantages et d'inconvénients à évaluer chacun - cela a sûrement été fait maintes et maintes fois? Peut-être que quelqu'un a au moins écrit quelques 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 char, si le numéro de maison doit être stocké dans 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 en tant que 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 m'intéresse principalement aux adresses américaines à ce stade, mais j'imagine qu'il existe certaines meilleures pratiques en ce qui concerne la préparation de l'éventualité d'une mondialisation également (par exemple, en nommant les champs de manière appropriée comme région au lieu de l'état ou du 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 quelques belles perles pour interpréter et valider des 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 leçon que j'ai apprise:
- Ne stockez rien numériquement.
- Enregistrez le pays et la zone administrative sous forme de codes ISO lorsque cela est possible.
- Lorsque vous ne savez pas, soyez laxiste à propos des champs obligatoires. Certains pays peuvent ne pas utiliser les champs que vous tenez pour acquis, même les choses 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 grossier au début, mais cela devient un problème sérieux lorsque la validation est également trop zélée.
Si vous souhaitez vous mondialiser, le seul conseil que je puisse vous donner 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, ainsi qu'un champ séparé pour un code postal (et faites attention à la façon dont vous décrivez cela pour faire face aux sensibilités nationales). Laissez l'utilisateur/le client décider comment écrire ses adresses.
Vous devriez certainement envisager de stocker le numéro de la maison comme un champ de caractères plutôt que comme un numéro, en raison de cas particuliers tels que les "demi-chiffres" 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.
Si vous avez besoin d'informations complètes sur la façon dont d'autres pays utilisent les adresses postales, voici un très bon lien de référence (Columbia University):
Guide compulsif de Frank sur les adresses postales
Adressage efficace pour le courrier international
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 généralement prendre en compte.
Je me souviens vaguement d'un problème avec les codes postaux norvégiens (je pense), qui étaient tous les 4 postes, sauf Oslo, qui en avait environ 18.
Je suis absolument certain qu'à partir du moment où nous avons commencé à utiliser les codes postaux géographiquement corrects pour toutes nos propres adresses nationales, un certain nombre de personnes ont commencé à se plaindre que leur courrier était arrivé 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 devait ê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 zone postale correcte prendrait ce courrier quelques jours de plus pour arriver, en raison de l'intervention indésirable qui était nécessaire dans le bon bureau postal pour le transmettre à la zone postale incorrecte ...
(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 un double direct.
Il y a sûrement beaucoup de réponses préexistantes (consultez les exemples de modèles de données sur DatabaseAnswers , par exemple). Beaucoup de réponses préexistantes sont défectueuses dans certaines circonstances (ne pas du tout choisir les réponses DB).
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, c'est souvent (ce qui ne signifie pas toujours ) judicieux à la fois d'enregistrer l'image de l'étiquette d'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 faire analyser et formater les humains et de laisser le SGBD simplement stocker les données.
À moins que vous ne fassiez des calculs sur les numéros de rue ou les codes postaux, vous invitez simplement la douleur future en les stockant sous forme de chiffres.
Vous pouvez é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 de l'introduction des alphas dans les codes?
Le coût de l'espace disque va être beaucoup moins cher que le coût de sa réparation plus tard ... y2k quelqu'un?
J'ai découvert que répertorier tous les champs possibles, de la plus petite unité discrète à la plus grande, est le moyen le plus simple. Les utilisateurs rempliront les champs qu'ils jugent appropriés. 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
*********************************
Ajout à ce que @ Jonathan Leffler et @ Paul Fisher ont dit
Si vous prévoyez un jour d'ajouter des adresses postales pour le Canada ou le Mexique à vos besoins, stocker postal-code comme une chaîne est un must. Le Canada a des codes postaux alphanumériques et je ne me souviens pas à quoi ressemble le Mexique.
Où est le "compromis" dans le stockage du Zip en tant que NUMBER ou VARCHAR? Ce n'est qu'un choix - ce n'est pas un compromis, sauf s'il y a des avantages pour les deux et que vous devez renoncer à certains avantages pour en obtenir d'autres.
À moins que la somme des zips ait une quelconque signification, les zips en tant que nombre ne sont pas utiles.
Cela peut être exagéré, mais si vous avez besoin d'une solution qui fonctionnerait avec plusieurs pays et que vous devez traiter par programmation des parties de l'adresse:
vous pouvez avoir une gestion d'adresse spécifique au pays à l'aide de deux tables: une table générique avec 10 colonnes VARCHAR2, 10 colonnes numériques, une autre table qui mappe ces champs à des invites et a une colonne de pays liant une structure d'adresse à un pays.
Si vous devez vérifier une adresse ou l'utiliser pour traiter des paiements par carte de crédit, vous aurez au moins besoin d'un peu de structure. Un bloc de texte de forme libre ne fonctionne pas très bien pour cela.
Le code postal est un champ facultatif commun pour valider les transactions par carte de paiement sans utiliser l'adresse complète. Ayez donc un champ séparé et de taille généreuse pour cela (au moins 10 caractères).
Inspiré par Database Answers
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 saisisse la valeur (sauf si vous souhaitez effectuer une analyse, par exemple, des codes postaux). Toutes ces entrées d'adresse ligne 1, adresse ligne 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).