Хорошо ли использовать целочисленный столбец для хранения почтовых индексов США в базе данных?

На первый взгляд, у меня есть два основных варианта хранения почтовых индексов в таблице базы данных:

  1. текст (вероятно, наиболее распространенный), т. е. char(5) или varchar(9) Для поддержки расширения +4
  2. числовое, то есть 32-разрядное целое число

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

    По своей природе он автоматически ограничивается только цифрами (в то время как без проверки стиль текста может хранить буквы и такие, которые, насколько мне известно, никогда не действительны в почтовом индексе). Это не означает, что мы могли бы/хотели/должны отказаться от проверки пользовательского ввода как обычно!
  • он занимает меньше места, будучи 4 байта (что должно быть достаточно даже для 9-значных почтовых индексов) вместо 5 или 9 байт.

Кроме того, кажется, что это не сильно повредит выводу дисплея. Это тривиально, чтобы ударить ToString() по числовому значению, использовать простую манипуляцию строкой, чтобы вставить дефис или пробел или что-то еще для расширения +4, и использовать форматирование строки для восстановления ведущих нулей.

Есть ли что-нибудь, что помешало бы использовать int в качестве типа данных для нас-только почтовые индексы?
11 45
database database-design street-address postal-code

11 ответов:

Числовой почтовый индекс-в некотором смысле-вводит в заблуждение.

Числа должны означать что-то числовое. Почтовые индексы не складываются, не вычитаются и не участвуют ни в каких числовых операциях. 12309-12345 не вычисляет расстояние от центра города Скенектади до моего района.

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

Поскольку почтовые индексы-это не номера, они просто кодируются с ограниченным доступом. алфавит-я предлагаю избегать числового поля. Экономия в 1 байт не стоит многого. И я думаю, что это Значение важнее, чем байт.

Edit.

" Что касается ведущих нулей...- это моя точка зрения. У чисел нет ведущих нулей. Наличие значимых ведущих нулей на почтовых кодах-еще одно доказательство того, что они не числовые.

104

Собираетесь ли вы когда-нибудь хранить почтовые индексы, не относящиеся к США? Канада - это 6 символов с некоторыми буквами. Я обычно просто использую поле из 10 символов. Дисковое пространство дешево, а необходимость переделывать модель данных-нет.

22

Используйте строку с проверкой. Почтовые индексы могут начинаться с 0, поэтому числовой тип не подходит. Кроме того, это относится и к международным почтовым кодам (например, UK, который может содержать до 8 символов). В маловероятном случае, когда почтовые индексы являются узким местом, вы можете ограничить его до 10 символов, но сначала проверьте ваши целевые форматы .

Ниже приведены регексы валидации для Великобритании, США и Канады.

Да, вы можете проложить, чтобы получить ведущие нули обратно. Тем не менее, вы теоретически выбрасывая информацию, которая могла бы помочь в случае ошибки. Если кто-то находит 1235 в базе данных, Это изначально 01235, или еще одна цифра была пропущена?

Лучшая практика говорит, что вы должны говорить то, что вы имеете в виду. Почтовый индекс-это код, а не число. Вы собираетесь добавлять/вычитать/умножать / делить почтовые индексы? И с практической точки зрения гораздо важнее, чтобы вы исключили удлиненные молнии.

17

Обычно вы используете нечисловой тип данных, такой как varchar, который позволяет использовать больше типов почтовых индексов. Если вы намертво настроены на разрешение только 5-значных [XXXXX] или 9-значных [XXXXX-XXXX] почтовых индексов, вы можете использовать символ(5) или символ(10), но я бы не рекомендовал его. Varchar является самым безопасным и наиболее вменяемый выбор.

Edit: следует также отметить, что если вы не планируете выполнять численные вычисления на поле, вы не должны использовать числовой тип данных. Почтовый индекс-это не число. в том смысле, что вы складываете или вычитаете против него. Это просто строка, которая обычно состоит из чисел, поэтому вам следует воздержаться от использования числовых типов данных для нее.

9

С технической точки зрения некоторые поднятые здесь вопросы довольно тривиальны. Я работаю с очисткой адресных данных наежедневной основе - в частности, очищая адресные данные со всего мира. Это не тривиальная задача при любом напряжении воображения. Когда дело доходит до почтовых индексов, вы Можете хранить их как целое число, хотя это может быть не "семантически" правильно. Дело в том, что данные имеют числовую форму независимо от того, рассматриваются ли они строго говоря числовое значение.

Однако очень реальный недостаток хранения их в виде числовых типов заключается в том, что вы потеряете возможность легко увидеть, были ли данные введены неправильно (т. е. имеют пропущенные значения) или если система удалила ведущие нули, что привело к дорогостоящим операциям по проверке потенциально недействительных почтовых индексов, которые были в противном случае правильными.

Также очень трудно заставить пользователя ввести правильные данные, если одним из последствий является задержка бизнеса. Пользователи часто не имеют терпение, чтобы ввести правильные данные, если это не сразу очевидно. Использование регулярных выражений является одним из способов гарантировать правильность данных, однако если пользователь вводит значение, которое не соответствует, и они отображаются с ошибкой, они могут просто опустить это значение полностью или ввести что-то, что соответствует, но в противном случае неправильно. Одним из примеров [использования канадских почтовых индексов] является то, что вы часто видите, как вводится A0A 0A0, который не является допустимым, но соответствует регулярному выражению для канадских почтовых индексов. Чаще всего это так. вводится пользователями, которые вынуждены указать почтовый индекс, но они либо не знают, что это такое, либо не все из них правильно.

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

7

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

Надеюсь, это поможет,

Билл

2

Нет, потому что

  • Вы никогда не делаете математические функции на почтовом индексе
  • может содержать тире
  • можно начать с 0
  • нулевые значения иногда интерпретируются как ноль в случае скалярных типов как целое число (например, когда вы экспортируете данные каким-то образом)
  • почтовый индекс, даже если это номер, является обозначением области, это означает, что это имя, а не числовое количество чего-либо
2

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

"10022-башмак"

Http://www.saksfifthavenue.com/main/10022-shoe.jsp

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

1

Integer-это хорошо, но он работает только в США, поэтому большинство людей не делают этого. Обычно я просто использую varchar (20) или около того. Вероятно, перебор для любого места.

0

Если бы вы использовали целое число для нас Zips, вы бы хотели умножить ведущую часть на 10 000 и добавить +4. Кодировка в базе данных не имеет никакого отношения к проверке ввода. Вы всегда можете потребовать, чтобы ввод был действительным или нет, но хранение зависит от того, насколько, по вашему мнению, изменятся ваши требования или USPS. (Подсказка: ваши требования изменятся .)

0

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

Из документов:

Вы можете использовать специальный префикс для записи чисел в десятичном, шестнадцатеричном, восьмеричном или двоичном форматах. Для десятичных чисел используйте префикс 0d, для шестнадцатеричных чисел используйте префикс 0x, для восьмеричных чисел используйте префикс 0 или 0о ...

0