Хорошо ли использовать целочисленный столбец для хранения почтовых индексов США в базе данных?
На первый взгляд может показаться, что у меня есть два основных варианта хранения почтовых индексов в таблице базы данных:
- Текст (вероятно, наиболее распространенный), т.е.
char(5)или жеvarchar(9)поддерживать расширение +4 - Числовое, то есть 32-разрядное целое число
И то, и другое удовлетворит требования данных, если предположить, что международных проблем нет. В прошлом мы, как правило, только что прошли текстовый маршрут, но мне было интересно, если кто-то делает обратное? Из краткого сравнения видно, что целочисленный метод имеет два явных преимущества:
- По своей природе он автоматически ограничивается только цифрами (тогда как без проверки текстовый стиль может хранить буквы и тому подобное, которые, насколько мне известно, никогда не действительны в почтовом индексе). Это не значит, что мы могли бы / должны / должны отказаться от проверки пользовательского ввода как обычно!
- Он занимает меньше места - 4 байта (что должно быть достаточно даже для 9-значных почтовых индексов) вместо 5 или 9 байтов.
Кроме того, кажется, что это не повредит выводу дисплея. Это тривиально, чтобы ударить ToString() для числового значения используйте простую манипуляцию со строками для вставки дефиса или пробела или чего-либо другого для расширения +4 и используйте форматирование строки для восстановления лидирующих нулей.
Есть ли что-то, что препятствует использованию int как тип данных для почтовых индексов только для США?
12 ответов
Числовой почтовый индекс вводит в заблуждение.
Числа должны означать что-то числовое. Почтовые коды не добавляют, не вычитают и не участвуют в каких-либо числовых операциях. 12309 - 12345 не вычисляет расстояние от центра города Скенектади до моего района.
Конечно, для почтовых индексов никто не смущен. Однако для других числовых полей это может сбивать с толку.
Поскольку почтовые индексы не являются числами - они просто кодируются ограниченным алфавитом - я советую избегать числовых полей. 1-байтовая экономия не стоит много. И я думаю, что это значение важнее байта.
Редактировать
"Что касается ведущих нулей..." это моя точка зрения. Числа не имеют ведущих нулей. Наличие значимых начальных нулей в почтовых индексах является еще одним доказательством того, что они не являются числовыми.
Собираетесь ли вы когда-нибудь хранить неамериканские почтовые коды? Канада 6 символов с некоторыми буквами. Я обычно просто использую поле из 10 символов. Дисковое пространство дешевое, нет необходимости переделывать модель данных.
Используйте строку с проверкой. Почтовые индексы могут начинаться с 0, поэтому числовой тип не подходит. Кроме того, это относится к международным почтовым индексам (например, к Великобритании, длина которых не превышает 8 символов). В маловероятном случае, когда почтовые индексы являются узким местом, вы можете ограничить его до 10 символов, но сначала проверьте целевые форматы.
Вот регулярные выражения для Великобритании, США и Канады.
Да, вы можете заполнить, чтобы вернуть ведущие нули. Тем не менее, вы теоретически выбрасываете информацию, которая может помочь в случае ошибок. Если кто-то находит 1235 в базе данных, это 01235 или пропущена другая цифра?
Лучшая практика говорит, что вы должны сказать, что вы имеете в виду. Почтовый индекс - это код, а не число. Собираетесь ли вы добавлять / вычитать / умножать / делить почтовые индексы? И с практической точки зрения гораздо важнее, чтобы вы исключали расширенные почтовые индексы.
Обычно вы будете использовать нечисловой тип данных, такой как varchar, который позволит использовать больше типов почтовых индексов. Если вы не можете использовать только 5-значные [XXXXX] или 9-значные [XXXXX-XXXX] почтовые индексы, вы можете использовать char(5) или char(10), но я бы не рекомендовал это делать. Varchar - самый безопасный и самый вменяемый выбор.
Изменить: Следует также отметить, что если вы не планируете делать численные расчеты на поле, вы не должны использовать числовой тип данных. Почтовый индекс - это не число в том смысле, что вы добавляете или вычитаете его. Это просто строка, которая обычно состоит из чисел, поэтому вам следует воздерживаться от использования числовых типов данных для нее.
Нет потому что
- Вы никогда не делаете математические функции на почтовый индекс
- Может содержать тире
- Может начинаться с 0
- Значения NULL иногда интерпретируются как ноль в случае скалярных типов, таких как целые числа (например, когда вы каким-либо образом экспортируете данные)
- Почтовый индекс, даже если это число, является обозначением области, то есть это имя, а не числовое количество чего-либо
С технической точки зрения некоторые вопросы, поднятые здесь, довольно тривиальны. Я ежедневно занимаюсь очисткой адресных данных - в частности, очищаю адресные данные со всего мира. Это не тривиальная задача для любого уровня воображения. Когда дело доходит до почтовых индексов, вы можете хранить их как целые числа, хотя это может быть "семантически" правильно. Дело в том, что данные имеют числовую форму, независимо от того, считаются ли они, строго говоря, числовыми.
Однако реальный недостаток хранения их в виде числовых типов заключается в том, что вы потеряете возможность легко увидеть, были ли введены данные неправильно (то есть, отсутствуют ли значения) или система удалила лидирующие нули, что привело к дорогостоящим операциям для проверки потенциально недействительных данных. почтовые индексы, которые в противном случае были правильными.
Также очень трудно заставить пользователя вводить правильные данные, если одним из последствий является задержка бизнеса. Пользователи часто не имеют терпения для ввода правильных данных, если это не сразу очевидно. Использование регулярных выражений является одним из способов гарантировать правильность данных, однако, если пользователь вводит значение, которое не соответствует, и у него отображается ошибка, он может просто вообще пропустить это значение или ввести что-то, что соответствует, но в противном случае является неправильным. Один из примеров [с использованием канадских почтовых индексов] заключается в том, что вы часто видите введенный A0A 0A0, который недопустим, но соответствует регулярному выражению для канадских почтовых индексов. Чаще всего это вводится пользователями, которые вынуждены предоставлять почтовый индекс, но они либо не знают, что это такое, либо не все правильно.
Одно из предложений заключается в проверке всей записи как единицы, подтверждающей, что почтовый индекс является правильным по сравнению с остальной частью адреса. Если это неверно, то предложение альтернативных действительных почтовых индексов для адреса облегчит для них ввод правильных данных. Аналогично, если почтовый индекс является правильным для адреса улицы, но номер улицы выходит за пределы домена этого почтового индекса, тогда предложите альтернативные номера улиц для этой комбинации почтового индекса / улицы.
Если у вас нет бизнес-требований для выполнения математических вычислений с данными почтового индекса, использование INT не имеет смысла. Вы закончили разработку.
Надеюсь это поможет,
Билл
Почтовый индекс - это действительно кодированное пространство имен, если вы об этом думаете. Традиционно цифры, а также дефис и заглавные буквы:
"10022-ОБУВЬ"
http://www.saksfifthavenue.com/main/10022-shoe.jsp
Реально, многим бизнес-приложениям не нужно будет поддерживать этот крайний случай, даже если он действителен.
Я думаю, что почтовый индекс в типе данных int может повлиять на ML-модель. Вероятно, чем выше код может создать выброс в данных для расчета
Недавно я узнал, что в Ruby одна из причин, по которой вы хотели бы избежать этого, состоит в том, что существуют некоторые почтовые индексы, начинающиеся с начальных нулей, которые - при сохранении в виде целого числа - будут автоматически преобразованы в восьмеричные.
Из документов:
Вы можете использовать специальный префикс для записи чисел в десятичном, шестнадцатеричном, восьмеричном или двоичном форматах. Для десятичных чисел используйте префикс 0d, для шестнадцатеричных чисел - префикс 0x, для восьмеричных чисел - префикс 0 или 0o…
Если бы вы использовали целое число для почтовых индексов США, вы бы хотели умножить ведущую часть на 10 000 и добавить +4. Кодировка в базе данных не имеет ничего общего с проверкой ввода. Вы всегда можете потребовать, чтобы ввод был действительным или нет, но хранение зависит от того, насколько вы думаете, ваши требования или USPS изменятся. (Подсказка: ваши требования изменятся.)
Целое число - это хорошо, но оно работает только в США, поэтому большинство людей этого не делают. Обычно я просто использую varchar(20) или около того. Вероятно, излишним для любой локали.