¿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.