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

Question

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

Американские почтовые индексы — 9.

Канадецу 7.

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

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

Редактировать] до:12 - разумный ответ на вопрос благодаря всем, кто внес свой вклад.

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

Чего вам не хватает, так это причины, по которой вам нужно, чтобы почтовый индекс обрабатывался особым образом.

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

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

Ты действительно нуждаться сгруппировать ваши заказы или транзакции по почтовому индексу?Я думаю, что нет, поскольку в разных странах существуют совершенно разные схемы в этой области.

Answer 5

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

Answer 6

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

Answer 7

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

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 

Answer 8

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

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

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