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

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

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

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

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

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

• Строительство
• Подземное здание
• Номер помещения (номер дома)
• Помещение Диапазон
• Улица
• Sub-Thoroughfare
• Двойной зависимый населенный пункт
• Район

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

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

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

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

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

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

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

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

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

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

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

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

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

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

Такие как

Via Eroi della Repubblica
89861 Tropea VV
Italy

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

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

• Сколько полей адреса вы бы использовали для Великобритании база данных?
• Вы разбиваете адреса на улицу / город / штат / zip?
• Что делать с повторяющимися суффиксами улиц?
• Рекомендации по хранению почтовых адресов в базе данных (СУБД) ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ОБНОВИТЬ:

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

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

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

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

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

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

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

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