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

Question

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

Las cremalleras estadounidenses son 9.

Canadiense es 7.

Estoy pensando 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.

Answer 1

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

Answer 2

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

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

Answer 3

¿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 en los códigos postales en todos los países, VARCHAR2 (9) o VARCHAR2 (10) serían suficientes para la mayoría, si no para todos los demás países.

A lo largo de la línea, siempre puede ALTERAR la columna para aumentar la longitud si surge la necesidad. Pero generalmente es difícil evitar que alguien, en algún lugar, decida volverse "creativo". y coloque 50 caracteres en un campo VARCHAR2 (50) por una razón u otra (es decir, porque quieren otra línea en una etiqueta de envío). También debe 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 recuperará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ía ser una buena cantidad de RAM 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 es posible que desee juntar todo en un código postal en lugar de desglosarlo por la extensión +4. En ese punto, es útil no tener que intentar SUBSTRAR los primeros 5 caracteres para el código postal.

Answer 4

Lo que falta es una razón por la que necesita que el código postal se maneje especialmente.

Si realmente no necesita TRABAJAR con un código postal, le sugiero que no se preocupe. Por trabajo, me refiero a hacer 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? Creo que no, ya que diferentes países tienen esquemas muy diferentes para este campo.

Answer 5

¿Normalización? Los códigos postales pueden usarse más de una vez y pueden estar relacionados con nombres de calles o ciudades. Tablas separadas.

Answer 6

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

Answer 7

El Reino Unido ha publicado normas: Catálogo de normas 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 

Answer 8

Si desea integrar códigos postales en la base de datos, es mejor usar 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.

Todas las demás bases de datos tienen más o menos probabilidades de tener 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 proporciona una interfaz más fácil usando json y ajax. Puede ver los límites aquí

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