Действительно ли это - хорошая идея использовать целочисленный столбец для хранения американских почтовых индексов в базе данных?

Я обновил с 5.5 до 5.6

composer.json

"minimum-stability":"dev",
"prefer-stable": true,

Это установит последние пакеты Laravel, затем возникнет проблема с TrustedProxies.

Установите последнюю версию прокси для Laravel 5.6.

Пожалуйста, используйте тег 4.0+ для Laravel 5.6:

composer require fideloper/proxy:~4.0

Подробнее

51
задан animuson 23 October 2013 в 16:36
поделиться

9 ответов

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

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

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

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


Edit .

«Что касается начальных нулей ...» - вот моя точка зрения. В числах нет ведущих нулей.

116
ответ дан 7 November 2019 в 09:44
поделиться

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

24
ответ дан 7 November 2019 в 09:44
поделиться

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

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


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

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

17
ответ дан 7 November 2019 в 09:44
поделиться

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

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

9
ответ дан 7 November 2019 в 09:44
поделиться

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

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

Билл

2
ответ дан 7 November 2019 в 09:44
поделиться

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

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

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

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

7
ответ дан 7 November 2019 в 09:44
поделиться

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

0
ответ дан 7 November 2019 в 09:44
поделиться

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

0
ответ дан 7 November 2019 в 09:44
поделиться

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

«10022-SHOE»

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

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

1
ответ дан 7 November 2019 в 09:44
поделиться
Другие вопросы по тегам:

Похожие вопросы: