Лучшая практика / Стандарт для хранения Адреса в Базе данных SQL
Я задаюсь вопросом, существует ли своего рода "стандарт" для хранения американских адресов в базе данных? Кажется, что это - общая задача, и должен быть своего рода стандарт.
То, что я ищу, является определенной схемой того, как таблицы базы данных должны работать и взаимодействовать, уже в третьей нормальной форме, включая типы данных (MySQL). Хороший документ UML работал бы.
Возможно, я просто ленив, но это - очень общая задача, и я уверен, что кто-то опубликовал эффективный способ сделать это где-нибудь. Я просто не знаю, где посмотреть, и Google не помогает. Укажите на меня на ресурс.Спасибо.
Править
Хотя это - больше общего вопроса, я хотел бы разъяснить свои определенные потребности.
Адреса будут использоваться для определения дорожных адресов местоположений событий. Эти адреса должны будут быть в формате, который может лучше всего ломаться и искаться и также использоваться любыми сторонними приложениями, с которыми я могу закончить тем, что связал свой источник данных.
ТАКЖЕ. Данные будут геокодироваться (долго, lat) на записи и храниться отдельно, таким образом, это должно будет соответствовать (все же нерешенный) протокол любого геокодера / приложение / библиотека делает это.
6 ответов
http://www.upu.int содержит стандарты формата для международных адресов. Публикация 28 на http://usps.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 MAIN ST SE APT B.
Если вы сохраняете всю адресную строку как одно поле в своей базе данных, введите и редактировать легко, но поиск может быть более трудным (например, в случае, если ЮГО-ВОСТОК - это улица ВОСТОК, как в Ю-ВОСТОК LN, или это ПРОЙКА, как в SE LANE ST?).
Если вы сохраните адрес в отдельных полях, поиск таких компонентов, как название улицы или квартиры, станет проще, но вам придется складывать все вместе для вывода, вам понадобится программное обеспечение CASS для правильного анализа, а также почтовые ящики, адреса сельских маршрутов и т. Д. и адреса APO / FPO имеют специальный синтаксический анализ.
Физическим местоположением с несколькими адресами в этом месте является либо многоквартирное здание, и в этом случае буквы / цифры после таких единиц, как APT и STE, обозначают адрес, либо это коммерческое агентство по получению почты (например, магазин UPS) и почтовый ящик / номер частного почтового ящика добавляется (например, 100 MAIN STE B PMB 102), или это бизнес с одной точкой доставки USPS, и почта маршрутизируется после доставки USPS (для чего обычно требуется отдельное поле почтового ящика, которое может понадобиться компании, но USPS выиграла в адресной строке).
Контакт с более чем одним физическим адресом обычно представляет собой компанию или лицо, имеющее почтовый адрес и почтовый ящик. Обратите внимание, что для каждого адреса обычно свой почтовый индекс.
Довольно типично, что одна бизнес-транзакция может иметь адрес доставки и адрес выставления счета (опять же, с разными почтовыми индексами). Информация, которую я храню для КАЖДОГО адреса:
* 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
Я обычно печатаю почтовые остановки где-то между именем человека и компанией, потому что страна содержит штат / почтовый индекс, который содержит город, содержащий адрес компании, содержащий остановку почты, которая содержит человека. Я использую программное обеспечение CASS для проверки и стандартизации адресов при вводе или редактировании.
Очень похожие вопросы задавались раньше.
Адреса в лучшем случае беспорядочные.
Это частично зависит от того, что вы хотите делать с адресами. Если вы собираетесь использовать их для рассылки по почте, вам просто нужно записать изображение, которое появится на адресной этикетке в удобной форме. Если вы собираетесь анализировать адрес, вам придется много работать.
Помните, что в первый раз, когда вам приходится иметь дело с кем-то за пределами США, все предыдущие правила сбиваются. Вы можете быть только в США, но будьте осторожны.
I изучал это некоторое время назад, но для международных адресов. Я не нашел многого в плане консенсуса. Однако для США я нашел лаконичное название Стандарт данных о проездах, ориентирах и почтовых адресах США (проект) :
http://www.fgdc.gov/standards/projects/FGDC -standards-projects / street-address / index_html
Я не думаю, что они действительно предоставляют какие-либо конкретные идеи схемы базы данных, но это может быть хорошей отправной точкой.
Мне приходилось пытаться сделать это раньше, и я нашел этот документ , который дает вам несколько указателей. В итоге я отложил свою схему, так как мое приложение действительно имеет дело с международными адресами.
Во-первых, как человек, который проводит большую часть своего профессионального дня, работая с адресами, скажу, что ими трудно управлять с точки зрения данных.
Если вы спросите 5 человек, по какому адресу они живут, вы получите 5 разных ответов. Хотя мы с вами можем сказать, что 123 Main Street Apt 1 и Apt 1 123 Main Street это один и тот же адрес, программа базы данных столкнется с проблемой.
Если вы используете адреса, ориентированные на Соединенные Штаты, сертифицированное программное обеспечение CASS практически любого производителя достаточно хорошо стандартизирует ваши адреса. Я бы рекомендовал следующий простой формат:
- Адрес 1
- Адрес 2
- Адрес 3
- Город
- Штат
- Почтовый индекс
- Почтовый индекс+4 (я бы сделал это для облегчения поиска при проверке дубликатов)
Однако, если вам нужен универсальный адрес, я бы обратил внимание на стандарт ADIS от IdeaAlliance. Этот стандарт можно использовать для разбивки (разбора) адресов практически из любой страны на соответствующие части. Затем их можно снова собрать вместе, используя шаблоны/компоненты, основанные на стандартах Всемирного почтового союза (UPU S42 Standard on International Postal Address Components and Templates).
Большим плюсом этого формата является то, что адреса, не существующие в почтовой базе данных типа CASS, могут быть введены и сохранены как отдельные части.
Во-первых, "лучший" способ хранения адреса сильно зависит от того, как он будет использоваться. Будет ли он использоваться только для справки или поиска по городу? Планируете ли вы адресовать конверты? Собираетесь ли вы интегрироваться с системой доставки, такой как FedEx или UPS? Будете ли вы хранить неамериканские адреса? Если вы собираетесь интегрироваться с чем-то, что осуществляет доставку, вам следует начать изучать CASS. Это спецификация для работы с адресами USPS. Существуют приложения, сертифицированные CASS, которые хранят и проверяют адреса. Таким образом, вторая лучшая практика заключается в том, чтобы попытаться избежать изобретения колеса и посмотреть, существует ли система, которая решит вашу проблему, особенно если вы собираетесь выйти на международный рынок. Вы хотите использовать тот факт, что кто-то другой проработал все детали того, как правильно и эффективно хранить адреса для многих стран мира, вместо того, чтобы заниматься этим самостоятельно.