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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Edit.

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Билл

Ответ 7

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

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

Ответ 8

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

"10022-ОБУВЬ"

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

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