J'ai besoin de stocker les codes postaux dans une base de données. Quelle doit être la taille de la colonne?

103

Je m'attends à ce que la colonne soit un VARCHAR2, dans ma base de données Oracle.

Les zips américains sont 9.

Le Canadien a 7 ans.

Je pense que 32 caractères serait une limite supérieure raisonnable

Qu'est-ce que je rate?

[EDIT] TIL: 12 est une réponse raisonnable à la question Merci à tous ceux qui ont contribué.

— EvilTeach
source

Lien utile, mais sa précision peut être un peu décevante. EG, il répertorie les codes postaux australiens comme étant de 7 caractères, alors qu'en fait ils sont 4. Réf: en.wikipedia.org/wiki/Postcodes_in_Australia et la liste des codes postaux disponible sur www1.auspost.com.au/postcodes .

— rossp

re: mon commentaire précédent - cela ne veut pas dire que cette liste n'est pas utile comme guide. En supposant que la liste se trouve du côté des codes postaux plus longs, la longueur la plus longue est de 9 caractères, donc 16 caractères ou environ devraient vous donner beaucoup d'espace pour respirer.

— rossp

La liste des pays est également un peu courte. Je suis sûr qu'il y a plus de pays sur la planète que ceux énumérés ...

— Robert Koritnik

2

Selon en.wikipedia.org/wiki/List_of_postal_codes , le plus long est de 12 caractères, si vous stockez le '-', sinon 11

— Neil McGuigan

@CMS: Vous voudrez peut-être mettre à jour le lien vers cette page wikipedia , cela semble être plus détaillé.

— Vajk Hermecz

51

En parcourant la page des codes postaux de Wikipedia , 32 caractères devraient être plus que suffisants. Je dirais que même 16 caractères, c'est bien.

— strager
source

8

Bon lien. Même en tenant compte de la ponctuation en US ZIP + 4, 10 caractères suffiraient pour n'importe quel pays pour autant que je sache.

— Jonathan Leffler

Sur la base de ce lien, de la page liée ci-dessus, j'irais avec 18 pour accueillir des pays comme le Chili: en.wikipedia.org/wiki/List_of_postal_codes

— mopo922

5

Le Chili est de 7 caractères. La page Web que vous avez référencée montre simplement la variance de ponctuation.

— EvilTeach

21

Comme déjà soulevé par @ neil-mcguigan, wikipedia a une page décente sur le sujet. Sur la base de ces 12 caractères devraient le faire: http://en.wikipedia.org/wiki/List_of_postal_codes

L'article de wikipedia répertorie environ 254 pays, ce qui est plutôt bien pour l' UPU (Union postale universelle) qui compte 192 pays membres.

— Vajk Hermecz
source

2

Notez que Montserrat est seulement 8 caractères, 1110-1350 dénote une plage. discovermni.com/about-montserrat/montserrat-post-codes

— Vajk Hermecz

Peut-être que Wikipédia a besoin d'être édité, car le code postal similaire pour Malte en a un générique comme "AAA NNNN". Cela ne me dérangerait pas d'avoir même 15 caractères car cela ne pourrait être que moins de problème plus tard si nous devons ajuster la longueur de la colonne, également avec une bonne utilisation des types de données, cela ne devrait pas prendre les 15 caractères de toute façon (peut-être varchar ou nvarchar ou autre?) .

— Manohar Reddy Poreddy

12

Pourquoi déclareriez-vous une taille de champ supérieure aux données réelles que vous prévoyez d'y stocker?

Si la version initiale de votre application prend en charge les adresses américaines et canadiennes (ce que je déduis du fait que vous appelez ces tailles dans votre question), je déclarerais le champ comme VARCHAR2 (9) (ou VARCHAR2 ( 10) si vous avez l'intention de stocker le trait d'union dans les champs ZIP + 4). Même en examinant les messages que d'autres ont publiés sur les codes postaux d'un pays à l'autre, VARCHAR2 (9) ou VARCHAR2 (10) serait suffisant pour la plupart sinon tous les autres pays.

En bas de la ligne, vous pouvez toujours MODIFIER la colonne pour augmenter la longueur en cas de besoin. Mais il est généralement difficile d'empêcher quelqu'un, quelque part, de décider d'être «créatif» et de mettre 50 caractères dans un champ VARCHAR2 (50) pour une raison ou une autre (c'est-à-dire parce qu'ils veulent une autre ligne sur une étiquette d'expédition). Vous devez également tester les cas limites (est-ce que chaque application qui affiche un ZIP gère 50 caractères?). Et avec le fait que lorsque les clients récupèrent des données de la base de données, ils allouent généralement de la mémoire en fonction de la taille maximale des données qui seront extraites, et non de la longueur réelle d'une ligne donnée. Ce n'est probablement pas un gros problème dans ce cas précis, mais 40 octets par ligne pourraient être une bonne quantité de RAM dans certaines situations.

En passant, vous pouvez également envisager de stocker (au moins pour les adresses américaines) le code postal et l'extension +4 séparément. Il est généralement utile de pouvoir générer des rapports par région géographique, et vous pouvez souvent vouloir tout mettre dans un code postal plutôt que de le décomposer par l'extension +4. À ce stade, il est utile de ne pas avoir à essayer de SUBSTRER les 5 premiers caractères du code postal.

— Justin Cave
source

4

Eh bien, en supposant que nous codons dans quelque chose de stupide comme Pro * C, avoir le champ suffisamment grand pour la croissance signifie que le code n'aura pas besoin d'être touché si l'utilisation augmente.

— EvilTeach

Oui, diviser le code postal américain en 5 et 4 chiffres peut avoir du sens, en fonction de ce que vous prévoyez de l'utiliser. Par exemple, si vous effectuez une sorte de correspondance d'adresses, vous voudrez peut-être d'abord faire correspondre le zip5 et résoudre les situations ambiguës avec le zip 9. Il est également utile d'utiliser un code de pays

— EvilTeach

3

Ce qui vous manque, c'est une raison pour laquelle vous avez besoin que le code postal soit traité spécialement.

Si vous n'avez pas vraiment besoin de TRAVAILLER avec un code postal, je vous suggère de ne pas vous en préoccuper. Par travail, je veux dire effectuer un traitement spécial plutôt que de simplement utiliser pour imprimer des étiquettes d'adresse, etc.

Créez simplement trois ou quatre champs d'adresse de VARCHAR2 (50) [par exemple] et laissez l'utilisateur entrer ce qu'il veut.

Avez-vous vraiment besoin de regrouper vos commandes ou transactions par code postal? Je ne pense pas, car différents pays ont des régimes très différents dans ce domaine.

— paxdiablo
source

Je suis d'accord. En utilisant un champ VARCHAR2, la réalité est que pour un champ comme le code postal, cela n'a vraiment pas d'importance. Un peu trop gros vaut mieux qu'ennuyer un client car il ne peut pas saisir ses coordonnées.

— Toby Allen

Et les varchars sont pratiques car les bases de données (au moins DB2) peuvent en optimiser le stockage, afin de ne pas gaspiller d'espace de stockage.

— paxdiablo

1

on ferait remarquer que le tri par pays et par code postal entraînera des tarifs postaux moins chers dans certains endroits.

— EvilTeach

10

Disgaree. À un moment donné, vous déciderez que vous devrez valider les adresses dans votre base de données (par exemple pour corriger les erreurs typographiques et de saisie de données) et c'est là que vous trouverez l'avantage de construire correctement votre modèle de données plutôt que de simplement tout pousser dans seaux.

— Gary Myers

1

@Pax Si vous remettez du courrier en vrac à Royal Mail pré-trié par le district principal (première lettre / deux lettres) du code postal, vous pouvez le faire livrer par MailSort, qui est moins cher que le courrier ordinaire de deuxième classe. Ce n'est qu'un exemple.

— Richard Gadsden

3

Normalisation? Les codes postaux peuvent être utilisés plusieurs fois et peuvent être liés à des noms de rue ou de ville. Table (s) séparée (s).

— Stéphan Eggermont
source

Intéressant. Un point de vue différent a simplement voté à la baisse sans aucune raison. +1

— EvilTeach

Un code postal fera généralement référence à un bloc d'un côté de la rue. Pour trouver une région plus large, vous devez sélectionner la première moitié du code postal. Avoir ces informations dans un tableau séparé n'aidera vraiment rien et serait plus compliqué à maintenir.

— RevNoah

4

@EvilTeach: Je parie qu'il a été rejeté parce que c'est hors sujet. Vous indique-t-il la taille d'une colonne pour stocker tous les codes postaux possibles dans le monde? Non.

— wmax

2

Les codes postaux canadiens ne comportent que 6 caractères, sous forme de lettres et de chiffres (LNLNLN)

— tegbains
source

3

Les codes postaux canadiens ont un espace au milieu "ANA NAN" qui est 7 caractères.

— EvilTeach

1

Mais l'espace est toujours au milieu, vous n'avez donc pas besoin de le ranger.

— Graeme Perrow

1

L'espace ne semble pas faire partie des données: "Remarque: les codes postaux canadiens sont toujours formatés dans le même ordre: caractère alphabétique / chiffre / alpha / chiffre / alpha / chiffre (par exemple K1A0B1)." Cela provient du site Web de Postes Canada.

— tegbains

2

Je ne pense pas que l'omission de l'espace ait quoi que ce soit à voir avec la «normalisation». C'est simplement un problème d'affichage. Comme des tirets dans les numéros de compte. Je ne le conserverais pas et je ne me fierais pas à lui pour identifier les codes postaux canadiens de préférence à un champ CountryCode (int) qui peut être indexé. Séparer la couche de données et de présentation est la bonne façon de le faire.

— Sam

2

Postes Canada préfère l'espace dans le code postal lors de l'adressage des enveloppes. Il est préférable de le stocker avec l'espace et de gérer la validation à l'entrée.

— RevNoah

2

Le Royaume-Uni a publié des normes: UK Government Data Standards Catalog

Max 35 characters per line

Adresse postale internationale:

Minimum of 2 lines and maximum of 5 lines for the postal delivery point 
details, plus 1 line for country and 1 line for postcode/zip code

La longueur du code postal britannique est:

Minimum 6 and Maximum 8 characters

— PodTech.io
source

1

Si vous souhaitez intégrer des codes postaux dans la base de données, il est préférable d'utiliser la base de données Geonames. Même si elle est difficile à utiliser et à comprendre, c'est la plus grande base de données géographique disponible gratuitement pour des utilisateurs comme nous.

Toutes les autres bases de données de ce type ont plus ou moins probablement les mêmes données et la même structure. Ils suppriment simplement certaines informations supplémentaires / redondantes de la base de données. Si vous le faites uniquement pour des systèmes à faible charge, utilisez leurs services gratuits, les limites sont attrayantes et offrent une interface plus simple en utilisant json et ajax. Vous pouvez voir les limites ici

Pour votre information, varchar (20) est suffisant pour stocker les codes postaux

— Jay Kapasi
source