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

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Ответ 3

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

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

Ответ 4

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

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

Например,

Via Eroi della Repubblica
89861 Tropea VV
Italy

Это немного отличается от порядка для американских адресов - во второй строке.

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

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

Также проверьте тег postal-code '.

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

Просто из шляпы я могу думать о следующей структуре:

• Страна
• Регион (штат/провинция)
• Местность (Город/муниципалитет)
• Суб-местность (графство/другое подразделение местности)
• Улица

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

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

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

Ответ 8

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

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

Я рекомендую вам не пытаться сделать его слишком умным.

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

UPDATE:

С другой стороны, все может быть сделано, но есть компромисс.

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

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

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

Как Amazon или eBay делают это? Они вывозятся на международном уровне. Имеют ли они специфические для локали функции пользовательского интерфейса? Я использовал только локали США.

Ответ 12

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