Подтвердить что ты не робот

Лучшая практика/стандарт для хранения адреса в базе данных SQL

Мне интересно, существует ли какой-то "стандарт" для хранения адресов США в базе данных? Кажется, это общая задача, и должен быть какой-то стандарт.

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

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

ИЗМЕНИТЬ


Хотя это более общий вопрос, я хотел бы уточнить свои конкретные потребности.

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

ТАКЖЕ. Данные будут привязаны к геокодированию (long, lat) и сохранены отдельно, поэтому он должен соответствовать протоколу (еще не определившимся) любого геокодера/приложения/библиотеки.

4b9b3361

Ответ 1

http://www.upu.int имеет стандарты формата для международных адресов. Публикация 28 на http://usps.com имеет стандарты формата США. CASS, например http://semaphorecorp.com, проверяет и стандартизирует адреса США.

USPS хочет, чтобы следующие неконцентрированные адресные компоненты были объединены в одну строку:

* house number
* predirectional (N, SE, etc)
* street
* suffix (AVE, BLVD, etc)
* postdirectional (SW, E, etc)
* unit (APT, STE, etc)
* apartment/suite number

Например, 102 N ГЛАВНАЯ ST SE APT B.

Если вы сохраняете всю адресную строку как одно поле в своей базе данных, ввод и редактирование просты, но поиск может быть более сложным (например, в случае, если SOUTH EAST LANE является улицей ВОСТОК, как в S EAST LN, или он LANE, как в SE LANE ST?).

Если вы сохраняете адрес в отдельных полях, поиск таких компонентов, как название улицы или квартиры, становится проще, но вам нужно добавить все вместе для вывода, вам нужно программное обеспечение CASS для правильного анализа, а также PO-боксы, адреса сельских маршрутов, и адреса APO/FPO имеют специальные синтаксические разборки.

Физическое местоположение с несколькими адресами в этом месте - это многоуровневое здание, и в этом случае буквы/числа после таких единиц, как APT и STE, обозначают адрес, или это коммерческое почтовое агентство (например, хранилище UPS) и почтовый ящик/частный почтовый ящик добавляется (например, 100 MAIN ST STE B PMB 102), или бизнес с одной точкой доставки USPS и почтой маршрутизируется после доставки USPS (что обычно требует отдельного поля mailstop, которое может понадобиться компании, но USPS выиграл 't на адресной строке).

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

Весьма типично, что у одной бизнес-транзакции может быть адрес доставки и платежный адрес (опять же, с разными почтовыми индексами). Информация, которую я сохраняю для КАЖДОГО адреса:

* name prefix (DR, MS, etc)
* first name and initial
* last name
* name suffix (III, PHD, etc)
* mail stop
* company name
* address (one line only per Pub 28 for USA)
* city
* state/province
* ZIP/postal code
* country

Я обычно печатаю почтовые стопки где-то между именем человека и компанией, потому что страна содержит государство /ZIP, в котором находится город, который содержит адрес, который содержит компанию, которая содержит почтовую остановку, которая содержит человека. Я использую программное обеспечение CASS для проверки и стандартизации адресов при вводе или редактировании.

Ответ 2

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

Если вы спросите 5 человек, на каком адресе они живут; вы обнаружите, что у вас есть 5 разных ответов. Пока вы и я можем сказать, что 123 Main Street Apt 1 и Apt 1 123 Main Street являются одним и тем же адресом, программа базы данных будет иметь проблемы.

Если вы используете центральные адреса Соединенных Штатов, сертифицированное CASS программное обеспечение практически любого поставщика будет стандартизировать ваши адреса достаточно хорошо. Я бы рекомендовал простой формат следующим образом:

  • Адрес 1
  • Адрес 2
  • Адрес 3
  • Город
  • Государство
  • Zip
  • Zip + 4 (я бы взял это, так что поиск проще при проверке дубликатов)

Однако, если вам нужен универсальный адрес, я бы посмотрел ADIS стандарт от IdeaAlliance. Этот стандарт может использоваться для разбивки (разбора) адресов из любой страны в соответствующие части. Затем их можно объединить, используя шаблоны/компоненты на основе стандартов Universal Postal Union (стандарт UPU S42 для международных компонентов и шаблонов почтовых адресов).

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

Ответ 3

Очень аналогичный questions были заданы ранее.

Адресы являются беспорядочными - в лучшем случае.

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

Помните, что в первый раз, когда вам приходится иметь дело с кем-то за пределами США, все предыдущие правила сбиваются с пути. Вы можете быть строго в США, но будьте осторожны.

Ответ 4

Я изучил это некоторое время назад, но для международных адресов. Я не нашел много на пути к консенсусу. Тем не менее, для США я нашел кратко названный США Thoroughfare, Landmark и Postal Address Data Standard (Draft):

http://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address/index_html

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

Ответ 5

Во-первых, "лучшее" средство хранения адреса в значительной степени зависит от того, как он будет использоваться. Это просто для справки или поиска по городу? Планируете ли вы обращаться с конвертами? Собираетесь ли вы интегрироваться с системой доставки, такой как FedEx или UPS? Будете ли вы хранить неамериканские адреса? Как только вы попадете в сферу интеграции с чем-то, что отправляется, вы должны начать смотреть на CASS. Это спецификация для обработки адресов USPS. Существуют приложения, сертифицированные CASS, которые будут хранить и проверять адреса. Таким образом, второй лучшей практикой было бы попытаться избежать повторного использования колеса и посмотреть, есть ли там система, которая решит вашу проблему, особенно если вы собираетесь идти на международный уровень. Вы хотите использовать тот факт, что кто-то еще разработал все подробные сведения о том, как правильно и эффективно хранить адреса для многих стран по всему миру, вместо того, чтобы самим проводить это расследование.

Ответ 6

Мне пришлось попробовать это сделать раньше, и я нашел этот документ, который дает вам несколько указателей. Я закончил выпуск моей схемы, так как мое приложение действительно имеет дело с международными адресами.