Зачем вам объявлять размер поля больше, чем фактические данные, которые вы ожидаете сохранить в нем?
Если первоначальная версия вашего приложения будет поддерживать адреса США и Канады (что я понимаю из того факта, что вы указали эти размеры в своем вопросе), я объявил бы поле как VARCHAR2 (9) ( или VARCHAR2 (10), если вы собираетесь хранить дефис в полях ZIP + 4). Даже если посмотреть на сообщения, сделанные другими в почтовые индексы разных стран, VARCHAR2 (9) или VARCHAR2 (10) будет достаточно для большинства, если не для всех других стран.
Вниз по линии, вы всегда можете изменить столбец, чтобы увеличить длину в случае необходимости. Но, как правило, трудно помешать кому-то где-то решить проявить «креативность» и вставить 50 символов в поле VARCHAR2 (50) по той или иной причине (т. Е. Потому, что им нужна другая строка на этикетке доставки). Вам также придется заниматься тестированием граничных случаев (будет ли каждое приложение, отображающее ZIP, обрабатывать 50 символов?). И с учетом того факта, что, когда клиенты извлекают данные из базы данных, они обычно выделяют память на основе максимального размера данных, которые будут извлечены, а не фактической длины данной строки. Вероятно, в этом конкретном случае это не такая уж большая проблема, но для некоторых ситуаций 40 байтов на строку могут быть приличной частью оперативной памяти.
Кроме того, вы можете также рассмотреть возможность хранения (по крайней мере для адресов США) почтового индекса и расширения +4 отдельно. Как правило, полезно иметь возможность создавать отчеты по географическим регионам, и вам часто может понадобиться собрать все в один почтовый индекс, а не разбивать его по расширению +4. На этом этапе полезно не пытаться выдать первые 5 символов почтового индекса.