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

StackOverflow https://stackoverflow.com/questions/893454

Вопрос

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

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

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

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

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

Есть ли что-нибудь, что препятствовало бы использованию int как тип данных для почтовых индексов только в США?

Это было полезно?

Решение

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

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

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

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


Редактировать.

«Что касается ведущих нулей…» — вот моя точка зрения.Числа не имеют ведущих нулей.Наличие значащих начальных нулей в почтовых индексах является еще одним доказательством того, что они не числовые.

Другие советы

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

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

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


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

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

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

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

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

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

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

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

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

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

Счет

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

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

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

«10022-ОБУВЬ»

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

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

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

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

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

От документы:

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top