Я ожидаю, что столбец будет VARCHAR2 в моей базе данных Oracle.
Почтовые индексы США - 9.
Канадцу 7 лет.
Я думаю, что 32 символа будут разумным верхним пределом
Что мне не хватает?
[EDIT] TIL: 12 - разумный ответ на вопрос Спасибо всем, кто внес свой вклад.
Просматривая страницу почтовых индексов Википедии, 32 символа должно быть более чем достаточно. Я бы сказал, что даже 16 символов - это хорошо.
Как уже отмечал @ neil-mcguigan, в Википедии есть достойная страница по этой теме. Исходя из этого, 12 символов должны делать это: http://en.wikipedia.org/wiki/List_of_postal_codes
В статье в Википедии перечислено около 254 стран, что неплохо с точки зрения UPU (всемирный почтовый Union) насчитывает 192 страны-члена.
Зачем объявлять размер поля больше, чем фактические данные, которые вы ожидаете в нем хранить?
Если первоначальная версия вашего приложения будет поддерживать адреса в США и Канаде (что я делаю вывод из того факта, что вы указываете эти размеры в своем вопросе), я бы объявил поле как VARCHAR2 (9) (или VARCHAR2 ( 10) если вы собираетесь хранить дефис в полях ZIP + 4). Даже если посмотреть на сообщения других пользователей о почтовых индексах в разных странах, VARCHAR2 (9) или VARCHAR2 (10) будет достаточным для большинства, если не для всех других стран.
Внизу строки вы всегда можете ИЗМЕНИТЬ столбец, чтобы при необходимости увеличить длину. Но, как правило, трудно помешать кому-то где-нибудь проявить «творческий подход» и заполнить 50 символов в поле VARCHAR2 (50) по той или иной причине (то есть потому, что им нужна другая строка на транспортной этикетке). Вы также должны иметь дело с тестированием граничных случаев (будет ли каждое приложение, отображающее ZIP, обрабатывать 50 символов?). И с тем фактом, что когда клиенты извлекают данные из базы данных, они обычно выделяют память на основе максимального размера данных, которые будут извлечены, а не фактической длины данной строки. Возможно, в этом конкретном случае не так много, но 40 байтов на строку могут быть приличным фрагментом ОЗУ для некоторых ситуаций.
Кроме того, вы также можете рассмотреть возможность хранения (по крайней мере, для адресов в США) почтового индекса и расширения +4 отдельно. Как правило, полезно иметь возможность создавать отчеты по географическому региону, и вам часто может потребоваться объединить все в почтовый индекс, а не разбивать его по расширению +4. На этом этапе полезно не пытаться вывести SUBSTR первых 5 символов почтового индекса.
Нормализация? Почтовые индексы могут использоваться более одного раза и могут быть связаны с названиями улиц или городов. Отдельный стол (ы).
То, что вам не хватает, - это причина, по которой вам нужно специально обрабатывать почтовый индекс.
Если вам действительно не нужно РАБОТАТЬ с почтовым индексом, я бы посоветовал не беспокоиться об этом. Под работой я имею в виду специальную обработку, а не использование только для печати адресных этикеток и т. Д.
Просто создайте три или четыре адресных поля VARCHAR2 (50) [например] и позвольте пользователю вводить все, что он хочет.
Вам действительно нужно сгруппировать заказы или транзакции по почтовому индексу? Думаю, нет, потому что в разных странах в этой сфере очень разные схемы.
Канадские почтовые индексы состоят всего из 6 символов в виде букв и цифр (LNLNLN).
Великобритания опубликовала стандарты: Каталог стандартов данных правительства Великобритании
Max 35 characters per line
Международный почтовый адрес:
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
Длина почтового индекса Великобритании:
Minimum 6 and Maximum 8 characters
Если вы хотите интегрировать почтовые индексы в базу данных, лучше всего использовать базу данных geonames. Несмотря на то, что ее сложно использовать и понять, это самая большая географическая база данных, свободно доступная таким пользователям, как мы.
Все остальные такие базы данных более или менее вероятно имеют те же данные и структуру. Они просто удаляют некоторую лишнюю / избыточную информацию из базы данных. Если вы просто делаете это для систем с низкой нагрузкой, используйте их бесплатные службы, ограничения привлекательны и обеспечивают более простой интерфейс с использованием json и ajax. Вы можете просмотреть ограничения здесь
Для вашей информации varchar (20) достаточно для хранения почтовых индексов.
