Есть ли общее проектирование баз данных конкретных адресов для всех адресов мира?

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

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

Например,

Via Eroi della Repubblica
89861 Tropea VV
Italy

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

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

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

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

---

Правка : обратный порядок региона и города - согласно UPU

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

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

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

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

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

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

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

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

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

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

• Страна
• Регион (Штат / провинция)
• Населенный пункт (Город / муниципалитет)
• Суб-населенная часть (округ / другая часть населенного пункта)
• Улица

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

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

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

Лен Сильверстон из Универсальной модели данных , известный как известный, рекомендует отдельную иерархию ГЕОГРАФИЧЕСКИХ ГРАНИЦ и в зависимости от того, насколько свободным вы хотите быть. принимать либо простые УЛИЧНУЮ АДРЕСНУЮ ЛИНИЮ , либо производные для отдельных стран.

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

ОБНОВЛЕНИЕ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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