Существует ли единый дизайн базы данных уличных адресов для всех адресов мира?


123

Я программист и, честно говоря, не знаю мировых структур уличных адресов, но как они устроены в моей стране :) Так какой же самый лучший и распространенный дизайн базы данных для хранения уличных адресов? Он должен быть таким простым в использовании, быстрым для запросов и динамическим, чтобы хранить все адреса в мире, которые идентифицируются только по одному идентификатору.
Большое спасибо



Вы спрашивали об адресах, но все ответы касаются почтовых адресов (в чем разница? ). Может, название следует изменить?
wrygiel

Ответы:


124

Можно представить адреса из множества разных стран в стандартном наборе полей. Основная идея именованного подъездного пути (проезда), на котором расположены названные или пронумерованные здания, довольно стандартна, за исключением некоторых случаев в Китае. Другие почти универсальные концепции включают в себя: наименование поселения (город / поселок / деревня), которое в общем можно назвать местностью; название региона и присвоение буквенно-цифрового почтового индекса. Обратите внимание, что почтовые индексы, также известные как почтовые индексы, являются чисто числовыми только в некоторых странах. Вам понадобится много полей, если вы действительно хотите быть универсальными.

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

Разумным форматом для хранения адресов будет следующий:

  • Адресные строки 1-4
  • Местонахождение
  • Область
  • Почтовый индекс (или почтовый индекс)
  • Страна

Адресные строки 1-4 могут содержать такие компоненты, как:

  • Здание
  • Sub-Building
  • Номер помещения (номер дома)
  • Диапазон помещений
  • проезд
  • Sub-магистраль
  • Двойной зависимый населенный пункт
  • Sub-Местность

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

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

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


1
Вы можете указать URL-адрес ВПС? (Да, я знаю, что смогу его найти, но лучшие ответы не заставляют людей искать.)
Джонатан Леффлер,

Попробуйте upu.int/post_code/en/… и выберите соответствующую страну в раскрывающемся
списке

Добавлен URL-адрес продукта UPU Post * Code
Эдвард Росс

17
Кроме того, в некоторых странах (например, в Ирландии) почтовые индексы не используются. Если бы у меня был цент за то количество раз, которое мне приходилось вводить (не применимо) в качестве почтового индекса, потому что это обязательный полевой человек. , , У меня уже было бы пять или шесть центов :)
Binary Worrier

если у ВПС есть списки для загрузки, в настоящее время они хорошо постарались скрыть их.
Jahmic

47

Взгляните на ответы базы данных . В частности, это касается многих случаев:

(Все символьные типы данных переменной длины)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

введите описание изображения здесь


Я не голосовал против, но думаю, что это могло бы сработать, только если бы все поля, кроме AddressId и Line1, были необязательными. В таком случае это не слишком полезно.

11
Типы данных важны - не во всех странах есть целочисленные почтовые индексы! Попросил коллегу быстро выяснить это у клиента из Канады.
Эрик

1
@Eric: За исключением полей Id, все эти поля являются символьными типами данных
Митч Уит,

2
В качестве идентификатора страны следует использовать двухбуквенный (или трехбуквенный) код страны ISO 3166. Предлагаемая схема позволяет хранить анализируемый адрес; он не говорит вам о том, как его отформатировать. (О, и в Великобритании есть буквенно-цифровые почтовые индексы - IP31 3GH, SE1W 9PQ и т. Д. Я думаю, что вторая группа всегда NAA; первая группа начинается с A и содержит по крайней мере один N (A = альфа, N = цифра), но меня ничто не удивило.)
Джонатан Леффлер

@ Нил: Совершенно верно. Существует так много различий по странам, что вы не можете использовать одну таблицу и ожидать, что db подтвердит ее.
Dave Sherohman 02

26

Спросите себя, какова основная цель хранения этих данных? Вы действительно собираетесь отправлять почту человеку по указанному адресу? Отслеживайте демографию, население? Уметь спрашивать у вызывающих абонентов их правильный адрес в рамках базовой аутентификации / проверки? Все вышеперечисленное? Ни один из вышеперечисленных?

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


Имеет смысл. Я ищу хорошее решение этой проблемы, но есть много разных. Как вы сказали: вероятно, лучше всего выбирать из реальных требований.
displayname

12

Иногда ближайший к улице адрес - это город.

Однажды у меня был проект по размещению всех средних школ Индии в Google Maps. Я написал красивую программу, используя Google API, и подумал, что это будет довольно просто.

Потом я получил данные от клиента. Некоторые школьные адреса были такими, как «Напротив рынка, рядом с парикмахером» или «Рядом со старой автобусной остановкой».

Это усложнило мою задачу, поскольку, к сожалению, API Google не поддерживает этот формат.


2
Азиатские адреса также известны этим. «73rd Block West Ninjang St, Building 2, Take Second Upper Elevator, Офисный комплекс рядом с ресторанным двориком, 468-й промышленный район, Шанхай, 456789» ...
ruhnet

9

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

<street address>
<zip> <town> <region>
<country>

Такие как

Via Eroi della Repubblica
89861 Tropea VV
Italy

Это сильно отличается от порядка для адресов в США - во второй строке.

См. Также вопросы SO:

Также проверьте тег " почтовый индекс ".


Изменить : обратный порядок региона и города - для ВПС


5

Может быть, это полезно: https://gist.github.com/259744 Для проекта я собрал таблицу с информацией обо всех странах мира, включая коды ISO, домен верхнего уровня, телефонный код, знак автомобиля, длину и регулярное выражение застежка - молния. Названия стран и комментарии, к сожалению, только на немецком языке ...


2

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

Проблема, с которой вы столкнетесь, заключается в том, что уровень географической иерархии в разных странах сильно различается. Черт возьми, в некоторых странах даже не везде есть «адреса».

Я рекомендую вам не делать это слишком умно.


2

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

Совершенно неожиданно я могу придумать следующую структуру:

  • Страна
  • Регион (штат / провинция)
  • Населенный пункт (город / муниципалитет)
  • Район (графство / другое подразделение населенного пункта)
  • улица

Но как запросить его достаточно быстро?

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

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


2

Лен Сильверстон, известный специалист по универсальной модели данных, рекомендует отдельную иерархию GEOGRAPHIC BOUNDARIESи в зависимости от того, в какой степени свободной формы вы готовы принять либо простые STREET ADDRESS LINEs, либо производные для каждой страны.


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

2

Нет, абсолютно нет. Если вы сравните то, как работают адреса в США и Японии , вы увидите, что это невозможно.

ОБНОВИТЬ:

Если подумать, все можно сделать, но есть компромисс.

Один из подходов состоит в том, чтобы смоделировать проблему с помощью таблиц адресов и address_attribute, с отношением 1: m между ними, что угодно можно смоделировать. Таблица address_attribute будет иметь pk, имя, значение и fk, который указывает обратно на pk его родительского адреса. Это похоже на использование карты с парами имя, значение.

Компромисс состоит в том, чтобы выполнять JOIN каждый раз, когда вам нужен адрес. Вы также должны опросить имена address_attributes, чтобы каждый раз выяснять, с чем вы имеете дело.

Другой подход - провести более всестороннее исследование того, как моделируются адреса во всем мире. В объектно-ориентированном мире у вас может быть западный класс Address (street1 / street2 / city / state / zip) и другие для Японии, Китая, столько, сколько необходимо для мозаичного адресного пространства. Тогда у вас будет основная таблица адресов и дочерние таблицы для других типов с соотношением между ними 1: 1.

Как это делают Amazon или eBay? Они отправляются по всему миру. Есть ли у них особенности пользовательского интерфейса, зависящие от локали? Я использовал только регион США.


1
что, если мне нужна большая часть адресов?
Арсен Мкртчян

Извините, я не слежу за вами здесь.
duffymo

2

Нет, стандартной схемы адресации нет. Обычно это варьируется от страны к стране. Даже Всемирный почтовый союз сказал в « Адресация мира» адрес для всех , которого нет. Лучшее решение для этого - использовать стандарты кода страны, состоящие из 2/3 букв, известные как ISO 3166, и рассматривать все остальное в соответствии со стандартами страны.

Однако, если вы действительно отчаялись использовать легкодоступные инструменты для своего проекта, вы можете попробовать Google Place API .


Мне очень нравится идея посмотреть, как Google Place API справляется со всем этим!
Эндрю Стейтц

1

Ваш дизайн должен сильно зависеть от вашей цели. Некоторые люди писали, как структурировать данные. Так что, если вы просто хотите отправить кому-то электронное письмо, это подойдет. Все начинает усложняться, если вы хотите использовать эти данные для навигации. Автомобильная навигация потребует дополнительных структур, содержащих информацию о трафике (например, дороги с односторонним движением), в то время как пешеходная навигация потребует большого количества дополнительных данных. Вот небольшой пример: в моем городе мой квартал находится рядом с парком. Рядом с парком находится бывший аэродром (фактически один из старейших в Европе), превращенный в музей авиации. Рядом с музеем авиации находится бизнес-парк. Номер улицы для музея - 39, а номера бизнес-парка начинаются с 39A. Таким образом, может показаться, что 39 и 39A близки, но для перехода от одного к другому требуется около мили (и даже больше, если вы едете на машине).
Это всего лишь небольшой пример, взятый из моего города, я думаю, вы, вероятно, найдете много исключений (особенно в сельских или более диких частях каждой страны).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.