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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

---

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

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

Answer 2

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

Answer 3

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

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

---

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

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

Bill

Answer 8

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

"10022-ОБУВЬ"

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

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

Answer 9

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

С Документы :

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

Answer 10

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