Necesito almacenar códigos postales en una base de datos. ¿Qué tan grande debe ser la columna?

103

Espero que la columna sea un VARCHAR2, en mi base de datos Oracle.

Las cremalleras estadounidenses son 9.

Canadiense tiene 7 años.

Creo que 32 caracteres serían un límite superior razonable

¿Qué me estoy perdiendo?

[EDITAR] TIL: 12 es una respuesta razonable a la pregunta Gracias a todos los que contribuyeron.

database oracle globalization postal-code EvilTeach
fuente
Enlace útil, sin embargo, su precisión puede estar un poco fuera de lugar. Por ejemplo, enumera los códigos postales australianos con 7 caracteres, cuando en realidad son 4. Ref: en.wikipedia.org/wiki/Postcodes_in_Australia y la lista de códigos postales disponible en www1.auspost.com.au/postcodes .
rossp
re: mi comentario anterior, eso no significa que esta lista no sea útil como guía. Suponiendo que la lista se equivoca en el lado de los códigos postales más largos, la longitud más larga es de 9 caracteres, por lo que 16 caracteres o aproximadamente deberían darle suficiente espacio para respirar.
rossp
Además, la lista de países es un poco corta. Estoy seguro de que hay más países en el planeta que los enumerados ...
Robert Koritnik
2
Según en.wikipedia.org/wiki/List_of_postal_codes , el más largo es de 12 caracteres, si está almacenando el '-', de lo contrario 11
Neil McGuigan
@CMS: es posible que desee actualizar el enlace a esta página de wikipedia , parece ser más detallado.
Vajk Hermecz

Respuestas:

51

Hojeando la página de códigos postales de Wikipedia , 32 caracteres deberían ser más que suficientes. Yo diría que incluso 16 caracteres son buenos.

extraño
fuente
8
Buen enlace. Incluso teniendo en cuenta la puntuación en el ZIP de EE. UU. + 4, 10 caracteres serían suficientes para cualquier país, por lo que yo sé.
Jonathan Leffler
Basado en este enlace, de la página enlazada arriba, iría con 18 para acomodar países como Chile: en.wikipedia.org/wiki/List_of_postal_codes
mopo922
5
Chile tiene 7 caracteres. La página web a la que hizo referencia simplemente muestra la variación de puntuación.
EvilTeach
21

Como ya planteó @ neil-mcguigan, wikipedia tiene una página decente sobre el tema. En base a eso, 12 caracteres deberían hacerlo: http://en.wikipedia.org/wiki/List_of_postal_codes

El artículo de wikipedia enumera ~ 254 países, lo cual es bastante bueno con respecto a la UPU (Unión Postal Universal) que tiene 192 países miembros.

Vajk Hermecz
fuente
2
Tenga en cuenta que Montserrat tiene solo 8 caracteres, 1110-1350 denota un rango. discovermni.com/about-montserrat/montserrat-post-codes
Vajk Hermecz
Posiblemente Wikipedia necesite ser editada, ya que el código postal de Malta de aspecto similar tiene uno genérico como "AAA NNNN". No me importaría tener incluso 15 caracteres porque solo podría ser un problema menor más adelante si tenemos que ajustar la longitud de la columna, también con el uso correcto de los tipos de datos, no debería tomar los 15 caracteres de todos modos (¿posiblemente varchar o nvarchar o similar?) .
Manohar Reddy Poreddy
12

¿Por qué declararía un tamaño de campo mayor que los datos reales que espera almacenar en él?

Si la versión inicial de su aplicación va a admitir direcciones de EE. UU. Y Canadá (lo que infiero del hecho de que menciona esos tamaños en su pregunta), declararía el campo como VARCHAR2 (9) (o VARCHAR2 ( 10) si tiene la intención de almacenar el guión en campos ZIP + 4). Incluso mirando las publicaciones que otros han hecho a los códigos postales de todos los países, VARCHAR2 (9) o VARCHAR2 (10) sería suficiente para la mayoría, si no para todos los demás países.

Más adelante, siempre puede ALTERAR la columna para aumentar la longitud si es necesario. Pero generalmente es difícil evitar que alguien, en algún lugar, decida ser "creativo" y rellenar 50 caracteres en un campo VARCHAR2 (50) por una razón u otra (es decir, porque quiere otra línea en una etiqueta de envío). También tiene que lidiar con la prueba de los casos límite (¿todas las aplicaciones que muestran un ZIP manejarán 50 caracteres?). Y con el hecho de que cuando los clientes recuperan datos de la base de datos, generalmente asignan memoria en función del tamaño máximo de los datos que se obtendrán, no de la longitud real de una fila determinada. Probablemente no sea un gran problema en este caso específico, pero 40 bytes por fila podrían ser una porción de RAM decente para algunas situaciones.

Además, también puede considerar almacenar (al menos para las direcciones de EE. UU.) El código postal y la extensión +4 por separado. En general, es útil poder generar informes por región geográfica y, con frecuencia, es posible que desee poner todo junto en un código postal en lugar de desglosarlo por la extensión +4. En ese momento, es útil no tener que intentar SUBSTR los primeros 5 caracteres del código postal.

Justin Cave
fuente
4
Bueno, asumiendo que estamos codificando en algo tonto como Pro * C, tener el campo lo suficientemente grande para el crecimiento significa que no será necesario tocar el código si aumenta el uso.
EvilTeach
Sí, dividir el código postal de EE. UU. En 5 y 4 dígitos puede tener sentido, dependiendo de para qué planeas usarlo. Por ejemplo, si está haciendo algún tipo de coincidencia de direcciones, es posible que desee hacer coincidir en el zip5 primero y resolver situaciones ambiguas con el zip 9. También es útil usar un código de país
EvilTeach
3

Lo que le falta es una razón por la que necesita que el código postal se maneje de manera especial.

Si realmente no necesitas TRABAJAR con un código postal, le sugiero que no se preocupe por eso. Por trabajo, me refiero a realizar un procesamiento especial en lugar de solo usarlo para imprimir etiquetas de dirección, etc.

Simplemente cree tres o cuatro campos de dirección de VARCHAR2 (50) [por ejemplo] y deje que el usuario ingrese lo que quiera.

¿Realmente necesita agrupar sus pedidos o transacciones por código postal? No lo creo, ya que los diferentes países tienen esquemas muy diferentes para este campo.

paxdiablo
fuente
Estoy de acuerdo. Al usar un campo VARCHAR2, la realidad es que para un campo como el código postal realmente no importa. Un poco demasiado grande es mejor que molestar a un cliente porque no puede ingresar sus datos.
Toby Allen
Y los varchars son útiles ya que las bases de datos (al menos DB2) pueden optimizar su almacenamiento, para no desperdiciar espacio de almacenamiento.
paxdiablo
1
uno señalaría que la clasificación por país y código postal dará como resultado tarifas postales más baratas en algunos lugares.
EvilTeach
10
Disgaree. En algún momento, decidirá que necesitará validar las direcciones en su base de datos (por ejemplo, para corregir errores tipográficos y de entrada de datos) y ahí es cuando encontrará el beneficio de construir correctamente su modelo de datos en lugar de simplemente introducir todo en cubos.
Gary Myers
1
@Pax Si entrega correo masivo al Royal Mail clasificado previamente por el distrito principal (primera letra / dos letras) del código postal, entonces puede recibirlo por MailSort, que es más barato que el correo normal de segunda clase. Ese es solo un ejemplo.
Richard Gadsden
3

¿Normalización? Los códigos postales pueden usarse más de una vez y pueden estar relacionados con nombres de calles o pueblos. Mesa (s) separada (s).

Stephan Eggermont
fuente
Interesante. Un punto de vista diferente simplemente se rechazó sin ninguna razón. +1
EvilTeach
Por lo general, un código postal hará referencia a un bloque en un lado de la calle. Para encontrar una región más amplia, debe seleccionar la primera mitad del código postal. Tener esta información en una tabla separada realmente no ayudará en nada y sería más complicado de mantener.
RevNoah
4
@EvilTeach: Apuesto a que fue votado en contra porque está fuera de tema. ¿Le dice qué tan grande debe ser una columna para almacenar todos los códigos postales posibles del mundo? No.
wmax
2

Los códigos postales canadienses tienen solo 6 caracteres, en forma de letras y números (LNLNLN)

tegbains
fuente
3
Los códigos postales canadienses tienen un espacio en blanco en el medio "ANA NAN". Son 7 caracteres.
EvilTeach
1
Pero el espacio siempre está en el medio, por lo que no es necesario almacenarlo.
Graeme Perrow
1
El espacio no parece formar parte de los datos: "Nota: los códigos postales canadienses siempre se formatean en la misma secuencia: carácter alfabético / numeral / alfa / numeral / alfa / numeral (por ejemplo, K1A0B1)". Eso es del sitio web de Canada Post.
tegbains
2
No creo que omitir el espacio tenga nada que ver con la 'normalización'. Es simplemente un problema de visualización. Como guiones en los números de cuenta. No lo almacenaría y no confiaría en él para identificar los códigos postales canadienses en lugar de un campo CountryCode (int) que se pueda indexar. Separar la capa de datos y presentación es la forma correcta de hacerlo.
Sam
2
Canada Post prefiere el espacio en el código postal cuando se envía a los sobres. Es mejor almacenarlo con el espacio y manejar la validación al ingresar.
RevNoah
2

El Reino Unido ha publicado estándares: Catálogo de estándares de datos del gobierno del Reino Unido

Max 35 characters per line

Dirección postal internacional:

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 longitud del código postal del Reino Unido es:

Minimum 6 and Maximum 8 characters
PodTech.io
fuente
1

Si desea integrar códigos postales en la base de datos, lo mejor es utilizar la base de datos geonames. Aunque es difícil de usar y comprender, es la base de datos geográfica más grande disponible gratuitamente para usuarios como nosotros.

Es más o menos probable que todas las demás bases de datos tengan los mismos datos y estructura. Simplemente eliminan información adicional / redundante de la base de datos. Si solo lo está haciendo para sistemas de baja carga, use sus servicios gratuitos, los límites son atractivos y proporcionan una interfaz más fácil usando json y ajax. Puedes ver los límites aquí

Para su información varchar (20) es suficiente para almacenar códigos postales

Jay Kapasi
fuente