database - Necesito almacenar códigos postales en una base de datos. ¿Qué tan grande debe ser la columna?
oracle globalization (8)
¿Normalización? Los códigos postales pueden usarse más de una vez y pueden estar relacionados con nombres de calles o ciudades. Mesa (s) separada (s)
Espero que la columna sea VARCHAR2, en mi base de datos Oracle.
US Zips es 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.
¿Por qué declararías un tamaño de campo más grande que los datos reales que esperas almacenar en él?
Si la versión inicial de su aplicación admite direcciones de EE. UU. Y Canadá (lo cual deduzco del hecho de que usted 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 los campos ZIP + 4). Incluso si miramos las publicaciones que otros han hecho sobre códigos postales en distintos países, VARCHAR2 (9) o VARCHAR2 (10) serían suficientes para la mayoría, si no para todos los demás países.
Más abajo, siempre puede ALTERAR la columna para aumentar la longitud en caso de necesidad. Pero en general es difícil evitar que alguien, en algún lugar, decida ser "creativo" y meter 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 (¿cada aplicación que muestre un ZIP maneja 50 caracteres?). Y con el hecho de que cuando los clientes recuperan datos de la base de datos, generalmente asignan la memoria en función del tamaño máximo de los datos que se obtendrán, no la longitud real de una fila determinada. Probablemente no es un gran problema en este caso específico, pero 40 bytes por fila podría ser un pedazo decente de RAM para algunas situaciones.
Como comentario adicional, también podría 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, puede querer juntar todo en un código postal en lugar de desglosarlo por la extensión +4. En ese punto, es útil no tener que tratar de SUBSTRAR los primeros 5 caracteres para el código postal.
Como ya planteó @ neil-mcguigan, wikipedia tiene una página decente sobre el tema. En base a eso, 12 caracteres deberían hacerlo: en.wikipedia.org/wiki/List_of_postal_codes
El artículo de la wikipedia contiene una lista de aproximadamente 254 países, lo que es bastante bueno con respecto a que la UPU (Unión Postal Universal) tiene 192 países miembros.
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
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.
Lo que te estás perdiendo es una razón por la cual necesitas que el código postal sea manejado especialmente.
Si realmente no necesita TRABAJAR con un código postal, le sugiero que no se preocupe por ello. Por trabajo, me refiero a hacer un procesamiento especial en lugar de utilizarlo 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.
Los códigos postales canadienses tienen solo 6 caracteres, en forma de letras y números (LNLNLN)
Si desea integrar códigos postales en la base de datos, es mejor utilizar la base de datos geonames. Aunque es difícil de usar y entender, es la base de datos geográficos más grande disponible para usuarios como nosotros.
Todas las otras bases de datos similares tienen más o menos la misma información y estructura. Simplemente eliminan parte de la información extra / redundante de la base de datos. Si solo lo hace 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. Puedes ver los límites here
Para su información varchar (20) es suficiente para almacenar códigos postales