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

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

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

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

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

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

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

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

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

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

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

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

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

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

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

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

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

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

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

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

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

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

Такие как

Via Eroi della Repubblica
89861 Tropea VV
Italy

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

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

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

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

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

Может быть, это полезно: 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 близки, но для перехода от одного к другому требуется около мили (и даже больше, если вы едете на машине).
Это всего лишь небольшой пример, взятый из моего города, я думаю, вы, вероятно, найдете много исключений (особенно в сельских или более диких частях каждой страны).