Мне нужно хранить почтовые индексы в базе данных. Насколько большим должен быть столбец?

103

Я ожидаю, что в моей базе данных Oracle столбец будет VARCHAR2.

Почтовые индексы США - 9.

Канадцу 7 лет.

Я думаю, что 32 символа будут разумным верхним пределом

Что мне не хватает?

[EDIT] TIL: 12 - разумный ответ на вопрос Спасибо всем, кто внес свой вклад.

database oracle globalization postal-code EvilTeach
источник
Ссылка полезная, но точность может быть немного ниже. Например, в нем перечислены австралийские почтовые индексы, состоящие из 7 символов, хотя на самом деле их 4. Ссылка: en.wikipedia.org/wiki/Postcodes_in_Australia и список почтовых индексов, доступный на www1.auspost.com.au/postcodes .
rossp
re: мой предыдущий комментарий - это не значит, что этот список бесполезен в качестве руководства. Предполагая, что список ошибается на стороне более длинных почтовых индексов, самая длинная длина составляет 9 символов, поэтому 16 символов или около того должны дать вам достаточно места для дыхания.
rossp
К тому же список стран немного короткий. Я уверен, что на планете больше стран, чем перечислено ...
Роберт Коритник
2
Согласно en.wikipedia.org/wiki/List_of_postal_codes , самый длинный - 12 символов, если вы сохраняете '-', иначе 11
Нил МакГиган
@CMS: Возможно, вы захотите обновить ссылку на эту страницу википедии , она выглядит более подробной.
Vajk Hermecz

Ответы:

51

Просматривая страницу почтовых индексов Википедии , 32 символа должно быть более чем достаточно. Я бы сказал, что даже 16 символов - это хорошо.

странник
источник
8
Хорошая ссылка. Насколько я могу судить, даже с учетом знаков препинания в US ZIP + 4, 10 символов будет достаточно для любой страны.
Джонатан Леффлер
Основываясь на этой ссылке, со страницы, указанной выше, я бы
выбрал
5
Чили состоит из 7 символов. Веб-страница, на которую вы ссылаетесь, просто показывает расхождения в пунктуации.
EvilTeach
21

Как уже отмечал @ neil-mcguigan, в Википедии есть достойная страница по этой теме. Исходя из этого, 12 символов должны сделать это: http://en.wikipedia.org/wiki/List_of_postal_codes

В статье в Википедии перечислено ~ 254 страны, что неплохо для ВПС (Всемирного почтового союза), который насчитывает 192 страны-члена.

Вайк Хермеч
источник
2
Обратите внимание, что Montserrat состоит всего из 8 символов, 1110-1350 обозначают диапазон. discovermni.com/about-montserrat/montserrat-post-codes
Vajk Hermecz
Возможно, Википедия нуждается в редактировании, поскольку почтовый индекс Мальты выглядит так же, как «AAA NNNN». Я был бы не против иметь даже 15 символов, потому что позже это может быть меньше проблем, если нам придется регулировать длину столбца, также при правильном использовании типов данных, в любом случае он не должен занимать все 15 символов (возможно, varchar или nvarchar или тому подобное?) .
Manohar Reddy Poreddy 08
12

Зачем объявлять размер поля больше, чем фактические данные, которые вы ожидаете в нем хранить?

Если первоначальная версия вашего приложения будет поддерживать адреса в США и Канаде (что я делаю вывод из того факта, что вы указываете эти размеры в своем вопросе), я бы объявил поле как VARCHAR2 (9) (или VARCHAR2 ( 10) если вы собираетесь хранить дефис в полях ZIP + 4). Даже если посмотреть на сообщения о почтовых индексах других стран, VARCHAR2 (9) или VARCHAR2 (10) будет достаточным для большинства, если не для всех других стран.

Внизу строки вы всегда можете ИЗМЕНИТЬ столбец, чтобы увеличить длину, если возникнет такая необходимость. Но, как правило, трудно помешать кому-то где-нибудь проявить «творческий подход» и заполнить 50 символов в поле VARCHAR2 (50) по той или иной причине (то есть потому, что им нужна другая строка на транспортной этикетке). Вы также должны иметь дело с тестированием граничных случаев (будет ли каждое приложение, отображающее ZIP, обрабатывать 50 символов?). И с тем фактом, что, когда клиенты извлекают данные из базы данных, они обычно выделяют память в зависимости от максимального размера данных, которые будут извлечены, а не фактической длины данной строки. Возможно, в этом конкретном случае не так много, но 40 байт на строку могут быть приличным фрагментом ОЗУ для некоторых ситуаций.

Кроме того, вы также можете рассмотреть возможность хранения (по крайней мере, для адресов в США) почтового индекса и расширения +4 отдельно. Как правило, полезно иметь возможность создавать отчеты по географическому региону, и вам часто может потребоваться объединить все в почтовый индекс, а не разбивать его с помощью расширения +4. На этом этапе полезно не пытаться вывести SUBSTR первые 5 символов почтового индекса.

Джастин Кейв
источник
4
Что ж, предполагая, что мы кодируем что-то глупое, например Pro * C, наличие достаточно большого поля для роста означает, что код не нужно будет трогать, если использование увеличится.
EvilTeach
Да, разбиение почтового индекса США на 5 и 4 цифры может иметь смысл, в зависимости от того, для чего вы планируете его использовать. Например, если вы выполняете какое-то сопоставление адресов, вы можете сначала сопоставить zip5 и разрешить неоднозначные ситуации с помощью zip 9. Также
полезно
3

То, что вам не хватает, - это причина, по которой вам нужно специально обрабатывать почтовый индекс.

Если вам действительно не нужно РАБОТАТЬ с почтовым индексом, я бы посоветовал не беспокоиться об этом. Под работой я имею в виду специальную обработку, а не просто печать адресных этикеток и так далее.

Просто создайте три или четыре адресных поля VARCHAR2 (50) [например] и позвольте пользователю вводить все, что он хочет.

Вам действительно нужно сгруппировать заказы или транзакции по почтовому индексу? Думаю, что нет, потому что в разных странах в этой сфере очень разные схемы.

Paxdiablo
источник
Я согласен. Использование поля VARCHAR2 в действительности для такого поля, как почтовый индекс, не имеет значения. Слишком большой - лучше, чем раздражать одного покупателя, потому что он не может ввести свои данные.
Тоби Аллен
И varchars удобны, поскольку базы данных (по крайней мере, DB2) могут оптимизировать их хранение, чтобы не тратить пространство для хранения.
paxdiablo
1
можно отметить, что сортировка по странам и почтовым индексам в некоторых местах приведет к снижению почтовых тарифов.
EvilTeach
10
Несогласие. Когда-нибудь в будущем вы решите, что вам нужно проверить адреса в своей базе данных (например, для исправления типографских ошибок и ошибок ввода данных), и именно тогда вы обнаружите преимущество правильного построения модели данных, а не просто вставлять все в нее. ведра.
Гэри Майерс
1
@Pax Если вы отправляете массовую почту в Royal Mail, предварительно отсортированную по главному округу (первая буква / две буквы) почтового индекса, то вы можете получить ее с помощью MailSort, что дешевле, чем обычная почта второго класса. Это всего лишь один пример.
Ричард Гадсден,
3

Нормализация? Почтовые индексы могут использоваться более одного раза и могут быть связаны с названиями улиц или городов. Отдельный стол (ы).

Стефан Эггермонт
источник
Интересный. Другая точка зрения просто отвергнута без всякой причины. +1
EvilTeach
Почтовый индекс обычно указывает на квартал на одной стороне улицы. Чтобы найти более широкий регион, вы должны выбрать первую половину почтового индекса. Хранение этой информации в отдельной таблице ничему не поможет, и ее будет сложнее поддерживать.
RevNoah 02
4
@EvilTeach: Бьюсь об заклад, он был отклонен, потому что он не по теме. Сообщает ли он вам, какого размера должен быть столбец для хранения всех возможных почтовых индексов мира? Нет.
wmax
2

Канадские почтовые индексы состоят всего из 6 символов в виде букв и цифр (LNLNLN).

Тегбайнс
источник
3
Почтовые индексы Канады имеют пробел посередине "ANA NAN" Это 7 символов.
EvilTeach
1
Но пространство всегда находится посередине, поэтому хранить его не нужно.
Грэм Перроу
1
Кажется, что пробел не является частью данных: «Примечание: почтовые индексы Канады всегда форматируются в одной и той же последовательности: буквенный знак / цифра / буква / цифра / буква / цифра (например, K1A0B1)». Это с веб-сайта Почты Канады.
tegbains
2
Я не думаю, что пропуск пробела имеет какое-либо отношение к «нормализации». Это просто проблема с отображением. Как тире в номерах счетов. Я бы не стал хранить его, и я бы не стал полагаться на него, чтобы идентифицировать канадские почтовые индексы, а не на поле CountryCode (int), которое можно проиндексировать. Разделение уровня данных и представления - правильный способ сделать это.
Сэм
2
Почта Канады предпочитает использовать пробелы в почтовом индексе при адресе конвертов. Лучше всего хранить его вместе с пробелом и обрабатывать проверку при входе.
RevNoah 02
2

Великобритания опубликовала стандарты: Каталог стандартов данных правительства Великобритании

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
PodTech.io
источник
1

Если вы хотите интегрировать почтовые индексы в базу данных, то лучше всего использовать базу данных geonames. Несмотря на то, что ее сложно использовать и понять, это самая большая географическая база данных, свободно доступная таким пользователям, как мы.

Все остальные такие базы данных более или менее вероятно имеют те же данные и структуру. Они просто удаляют некоторую лишнюю / избыточную информацию из базы данных. Если вы просто делаете это для систем с низкой нагрузкой, используйте их бесплатные службы, ограничения привлекательны и обеспечивают более простой интерфейс с использованием json и ajax. Вы можете просмотреть лимиты здесь

К вашему сведению, varchar (20) достаточно для хранения почтовых индексов.

Джей Капаси
источник