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

Question

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

Les US Zips sont 9.

Canadien a 7 ans.

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

Qu'est-ce que je rate?

Answer 1

Ici vous trouverez une liste des codes postaux internationaux formats.

Answer 2

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

Answer 3

Pourquoi voulez-vous déclarer un champ de plus grande taille que les données réelles vous attendent à la boutique?

Si la première version de l'application va NOUS soutenir et adresses Canadiennes (dont je suis déduire du fait que vous appelez ces tailles dans votre question), j'aimerais déclarer le terrain comme VARCHAR2(9) (ou VARCHAR2(10) si vous avez l'intention de stocker le trait d'union dans ZIP+4 champs). Même en regardant les posts d'autres personnes ont fait de codes postaux à travers le pays, VARCHAR2(9) ou VARCHAR2(10) serait suffisante pour la plupart, si pas tous les autres pays.

En bas de la ligne, vous pouvez toujours MODIFIER la colonne à l'augmentation de la longueur en cas de nécessité. Mais il est généralement difficile d'empêcher quelqu'un, quelque part, de décider d'obtenir des "créatifs" et des trucs de 50 caractères dans un VARCHAR2(50) terrain pour une raison ou une autre (c'est à dire parce qu'ils veulent une autre ligne sur une étiquette d'expédition). Vous avez également à traiter avec les tests de la limite des cas (chaque application qui affiche un ZIP poignée de 50 caractères?). Et avec le fait que lorsque les clients sont de la récupération de données à partir de la base de données, ils sont généralement de l'allocation de mémoire basé sur la taille maximale des données qui seront récupérées, pas la longueur réelle d'une ligne donnée. Probablement pas une affaire énorme dans ce cas précis, mais 40 octets par ligne pourrait être un morceau décent de RAM pour certaines situations.

En aparté, vous pouvez aussi envisager de stockage (au moins pour les adresses des états-unis), le code POSTAL et le +4 extension séparément. Il est généralement utile d'être en mesure de générer des rapports par région géographique, et vous pouvez souvent envie de tout mettre dans un code POSTAL ensemble plutôt que de le décomposer par l' +4 extension. À ce stade, il est utile de ne pas avoir à essayer de SUBSTR la première 5 caractères du code POSTAL.

Answer 4

Ce qui vous manque c'est une raison pour laquelle vous avez besoin du code postal pour être traitées spécialement.

Si vous n'avez pas vraiment besoin de TRAVAILLER avec un code postal, je suggère de ne pas s'inquiéter à ce sujet. Par le travail, je veux faire un traitement spécial pour plutôt que de simplement utiliser pour imprimer des étiquettes d'adresses, et ainsi de suite.

Il suffit de créer trois ou quatre champs d'adresse de VARCHAR2(50) [par exemple] et de laisser l'entrée de l'utilisateur ce qu'ils veulent.

Avez-vous vraiment besoin de regrouper vos commandes ou des transactions par code postal? Je ne pense pas, puisque les différents pays sont très différents régimes pour ce champ.

Answer 5

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