Question

Quel est le "meilleur" moyen de stocker des adresses internationales dans une base de données ?Répondez sous forme de schéma et d’explication des raisons pour lesquelles vous avez choisi de normaliser (ou non) comme vous l’avez fait.Expliquez également pourquoi vous avez choisi le type et la longueur de chaque champ.

Note:Vous décidez quels champs vous jugez nécessaires.

Était-ce utile?

La solution

Texte brut et libre.

Valider tous les codes postaux du monde est trop difficile ;une liste fixe de pays est trop sensible politiquement ;l'état/région/autre subdivision administrative obligatoire est tout simplement inapproprié (on me demande trop souvent dans quel comté je vis - alors que ce n'est pas le cas, car le Grand Londres n'est pas du tout un comté).

Plus précisément, c’est tout simplement inutile.Il est très peu probable que votre application modélise des adresses de manière sérieuse.Si vous souhaitez une adresse postale, demandez l'adresse postale.La plupart des gens ne sont pas assez stupides pour indiquer autre chose qu'une adresse postale, et s'ils le font, ils peuvent dire adieu à leur nouvel article acheté.

L'exception à cette règle est si vous faites quelque chose qui est de toute façon naturellement limité à un seul pays.Dans cette situation, vous devez demander, par exemple, la paire { code postal, numéro de maison }, qui suffit à identifier une adresse postale.J'imagine que vous pourriez réaliser des choses similaires avec le code postal étendu aux États-Unis.

Autres conseils

Dans le passé, j'ai modélisé des formulaires qui devaient être internationaux d'après les formulaires d'adresse de livraison UPS/Fedex sur leurs sites Web (je pensais que s'ils ne savaient pas comment gérer une commande internationale, nous étions tous arrosés).Les champs qu'ils utilisent peuvent être utilisés comme référence pour configurer votre schéma.

En général, vous devez comprendre pourquoi vous souhaitez une adresse.Est-ce pour l'expédition/la poste ?Il n’y a alors qu’une seule exigence : que le pays se sépare.Les autres lignes sont de forme libre, à remplir par l'utilisateur.La raison en est la stratégie de transfert courante pour le courrier :tout courrier entrant destiné à un pays étranger est transféré sans regarder les autres lignes d'adresse.Par conséquent, les informations détaillées sont analysées uniquement par le trieur de courrier situé dans le pays lui-même.Tout comme le receveur, ils connaîtront les conventions nationales.

(UPS peut regrouper certains petits pays européens, par exemple.tous les Pays-Bas sont probablement desservis depuis la Belgique - l'idée est toujours valable.)

Je pense que l'ajout du pays/ville et du texte de l'adresse conviendra.le pays et la ville doivent être séparés pour les rapports.Gestionnaires toujours demandez ce genre de rapports auxquels vous ne vous attendez pas et je ne préfère pas exécuter une requête LIKE via une grande base de données.

Ne pas accorder un respect indu à Facebook.Cependant, la structure globale de la base de données semble être négligée dans de nombreuses applications Web lancées quotidiennement.Évidemment, je ne pense pas qu'il existe une solution parfaite couvrant toutes les variables potentielles avec une structure d'adresse sans un travail acharné.Cela dit, combiné à la saisie semi-automatique, Facebook parvient à prendre les données de localisation et à éliminer la majorité de leurs entrées redondantes.Pour ce faire, ils organisent suffisamment bien leur base de données pour fournir au client des informations de saisie semi-automatique en temps réel à faible coût et avec peu d'erreurs, ce qui lui permet de choisir plus ou moins l'emplacement correct dans une liste existante.

Je pense que la meilleure solution consiste à accéder à une base de données tierce contenant la portée géographique souhaitée et à l'utiliser pour initialiser les informations de localisation de vos utilisateurs.Cela vous permettra d’éviter de faire le travail de base pour créer le vôtre.Avec un peu de chance, vous pouvez réduire la charge sur votre serveur en permettant à vos nouveaux utilisateurs de recevoir les informations de saisie semi-automatique correctes directement de votre fournisseur tiers.À terme, vous pourrez remplir la plupart des informations de saisie semi-automatique pour les informations de localisation telles que la ville, le pays, etc.à partir des informations contenues dans votre propre base de données à partir des données saisies par l'utilisateur.

Vous devez fournir un peu plus de détails sur la manière dont vous envisagez d'utiliser les données.Par exemple, des champs tels que Ville, État, Pays peuvent soit être du texte dans la table unique, soit être des codes liés à une table distincte avec une clé étrangère.

Le plus simple serait

Adresse_line_01 (obligatoire, non vierge) Adresse_line_02 Adresse_line_03 Landmark City (obligatoire) Pin (requis) Province_District State (requis) (obligatoire)

Tout ce qui précède peut être au format Texte/Unicode avec des longueurs de champ appropriées.

Numéros de téléphone, le cas échéant.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top