Tipo de columna para ZipCode en la base de datos PostgreSQL?

Question

¿Cuál es el tipo de columna correcto para mantener los valores de ZipCode en la base de datos PostgreSQL?

Answer 1

Es algo así como xxxxx-xxxx, por lo que se recomienda varchar(10).

Si desea verificar la sintaxis de los valores en la base de datos, puede crear un tipo domain para los códigos postales.

CREATE DOMAIN zipcode varchar(10) 
    CONSTRAINT valid_zipcode 
    CHECK (VALUE ~ '[A-Z0-9-]+'); -- or a better regular expression 

Se puede echar un vistazo a this sitio, que propone esta expresión regular:

(^\d{5}(-\d{4})?$)|(^[ABCEGHJKLMNPRSTVXY]{1}\d{1}[A-Z]{1} *\d{1}[A-Z]{1}\d{1}$) 

Pero usted debe comprobar que funciona para la sintaxis de expresiones regulares PostgreSQL.

Answer 2

depende del tipo de zip que desee. si está seguro de que solo necesitará almacenar los 5 dígitos estándar, entonces usar un int le ahorrará más espacio.

Sin embargo, si necesita hacer el 5 + 4 extendido, entonces un campo de caracteres de 10 dígitos es el mejor. Personalmente sugiero que, como lo hace más fácil en el futuro, si terminan necesitando códigos postales internacionales, 10 dígitos cubre casi cualquier formato de código postal posible que haya encontrado.

Answer 3

Estoy totalmente en desacuerdo con los consejos presentados aquí.

1. La respuesta aceptada acepta cosas que no son dígitos.
2. La pregunta es sobre códigos postales, no códigos postales.
3. Si asumimos que la publicación es incorrecta y significa códigos postales internacionales, hay caracteres que aparecen en códigos postales internacionales que no aparecen en esa lista, y muchos códigos postales internacionales, y también los nacionales, pueden tener más de diez personajes
4. Si realmente responder a la pregunta que hicieron, sobre códigos postales, entonces no debería haber alojamiento para cualquier cosa menos dígitos (y posiblemente el guión)
5. códigos postales de Estados Unidos pueden tener hasta 11 dígitos de longitud (13 caracteres que cuentan los dos guiones): hay un zip, un zip + 4 y un zip + 6 (que los programadores llamarían zip + 4 + 2); el último es utilizado por rascacielos, universidades, etc.
6. Los códigos postales de EE. UU. siempre son enteros no negativos y, por lo tanto, no deben almacenarse como datos de texto, lo que está sujeto a problemas de representación no canónicos (pregunte a cualquiera que haya hecho un sistema aproximadamente esa vez descubrieron que su código postal 00203 no coincidía con el código postal 203 que accidentalmente obtuvieron al analizar innecesariamente representaciones de cadenas)
7. Si finge que realmente está rastreando códigos postales internacionales, la secuencia corta de caracteres limita los campos de texto aquí ni siquiera comienzan a hacer el trabajo. La palabra "China" viene a la mente.

mi opinon:

1. Decidir si en realidad estás manejo de EE.UU. códigos postales o internacional
2. Si usted está manejando códigos postales de Estados Unidos, rastrearlos enteros sin signo como, y Déjalos con ceros cuando el texto los represente. (Piense en las marcas temporales de Unix y las representaciones TZ locales si necesita comprender por qué será más sencillo a largo plazo).
3. Si está manipulando códigos postales internacionales, guárdelos en una cadena unicode ilimitada, átelos al país donde se encuentran. representar y validar país por país con restricciones de verificación. Este problema es mucho más difícil de lo que parece desde el principio. Las direcciones internacionales son algunas de las cosas menos estandarizadas en la Tierra. Espere a averiguar cómo funcionan los números de las casas japonesas, o por qué el código postal británico 6 tiene los vacíos que tiene.