Как международные географические адреса должны храниться в реляционной базе данных?

https://stackoverflow.com/questions/1159756

18-09-2019
|

Вопрос

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

Есть ли смысл в разделении по -разному форматированному адресу на разные таблицы? Например, есть таблица для USAADDRESS, CanadianAddress, Ukaddress ...?

Решение

Я суммирую свои мысли из моего сообщения в блоге - Урок хранения адреса.

В моем текущем проекте [я работаю в логистической компании] мы храним международные адреса. Я провел исследования по адресам по всему миру при разработке этой части базы данных. Там много разных форматов. В западном мире мы склонны использовать довольно равномерный формат - несколько различий, но в основном они:

Номер улицы - числовое
Название дома или здания - [varchar - в Великобритании некоторые дома/здания идентифицируются по имени, а не по номеру
Уличный номер суффикс VARCHAR, хотя в большинстве случаев, char (1) было бы достаточно
- A, B и т. Д.
Название улицы Varchar
Уличный тип Varchar или int, если у вас есть таблица Streettypes
- До сих пор я нашел 262 уникальных типа в английском мире, вероятно, есть больше, и не забывайте о других языках, то есть Strasse, Rue и т. Д.
Уличное направление Varchar (2)
- N, E, S, W, NE, SE, NW, SW
тип адреса Varchar или int, если у вас есть таблица AddressTypes
- Почтовый ящик
- Квартира
- Строительство
- Пол
- Офис
- Набор
- так далее...
Идентификатор типа адреса Varchar
- То есть номер коробки, номер квартиры, номер пола запомнить номера квартир и офисы иногда имеют буквенно -цифровую информацию - например, 1a
Местный муниципалитет Varchar или int, если у вас есть таблица муниципалитетов
- Например, если ваша деревня/деревня появляется в адресе перед городом.
Город/Город Varchar или int, если у вас есть таблица городов
Управляющий район Varchar или int, если у вас есть таблица районов
- Государство (США)
- Провинция (Канада)
- Федеральный округ (Мексика)
- Графство (Великобритания)
- так далее...
Почтовая зона Varchar
- Zip (США)
- Почтовый кодекс (Канада, Мексика)
- Почтовый индекс (Великобритания)
Страна Varchar или int, если у вас есть таблица стран

Похоже, что это охватывает большинство стран, но упорядочение полей может отображаться по -разному. Вы можете найти список форматов дисплея в http://www.bitboost.com/ref/international-address-formats.html#formats

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

Отвечая на ваш вопрос о разделении адресов на разные страны, я бы не предложил его, это просто усложнит жизнь в других областях - например, отчетность. Формат, который я предоставил, охватывает все адреса в нашей логистической базе данных, которая без каких -либо проблем охватывает США, Канаду, Мексику и Великобритания. Это также охватывает все наши европейские, китайские, японские и малазийские адреса. Я не могу говорить за другие страны, но мне еще не приходилось хранить адрес из страны, который эти области не поддерживают.

Я не предлагаю обратиться к формату Address1, Address2, Address3, предлагаемому другими и замеченными во многих базах данных, потому что информация о адресах диапазона из буквенно -цифровой строки не так просто, как это может показаться, особенно если данные не введены правильно , из -за дезинформации, опечатки, неправильного написания и т. Д. Если вы разделяете свои поля, вы можете использовать алгоритмы расстояния для проверки вероятного значения, используйте вероятность проверки названия улицы против почтового кода и номера улицы или проверить провинцию и город против названия улицы и т. Д. Попробуйте Делать что -то из этого, когда у вас есть строка, обозначающая весь ваш адрес улицы. Это не тривиальный вопрос ни на одном участке воображения.

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

Одним из предостережений, о которых нужно знать, являются дороги с именами, которые также являются типами улиц - если вы освещаете Канаду, вам нужно знать о «Avenue Road» в Торонто, которые будут сбить вас с толку, если вы используете адрес1, 2 , 3 формат. Это, вероятно, происходит и в других местах, хотя я не знаю о них - этого единственного экземпляра было достаточно, чтобы я мог кричать WTF?!

Другие советы

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

Держите вещи простыми.

Стрит -тип, упомянутый Benalabaster, вызовет проблемы, когда вы начнете работать с языками, отличными от изолирующих языков, таких как английский или испанский.

Чтобы показать вам, как плохие вещи могут попасть в дикую природу: «Генриетт Роланд Холстстраат» в Амстердаме, созданный из «Генриетты» + «Роланд Холст» + «Страат», который может быть сокращена как «Роланд Холстстраат», или « Роланд Холстстр. ", Или с ошибкой как" Hrholststr ". или «Генриетта Роланд-Холст Страат», в зависимости от погоды. Если у вас нет актуального реестра улиц для каждой страны на земле, вы никуда не поедете.

И, наконец, будьте осторожны, что в некоторых многоязычных странах имена могут отличаться от одного языка на другом! Например, в Брюсселе, где во многих улицах есть французские а также Голландское имя: «Avenu du Port» и «Havenlaan», в зависимости от предпочтительного языка адресата. (Google Maps показывает оба имена попеременно, просто чтобы быть на безопасной стороне.)

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

Это зависит от того, что вы хотите с этим делать.

Я всегда обнаружил, что всегда проще использовать адреса для других целей (например, проверка в отношении данных USPS или получение скоростей доставки от UPS/FedEx), если они разделены.

Вот что я обычно использую для адресов:

Адресная строка 1
Адресная строка 2
Адресная строка 3
Город
Область, край
Почтовый Код
округ
Страна

В ответ на редактирование: Для большинства ситуаций я не вижу использования. В таблице, в которой я перечислен, есть достаточно полей (и достаточно общая) для адресов большинства страны.

Адрес

В качестве полярного напротив отличного ответа, предоставленного @benalabaster, вы можете просто иметь:

address       TEXT(300)
postal_code   VARCHAR(15)
country_code  VARCHAR(2)

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

Страна

Ваш страновой стол будет выглядеть следующим образом:

country_code  VARCHAR(2)
country_name  VARCHAR(255)

Кроме того, вы могли бы иметь один из следующих:

postal_code_required  TINYINT(1)
postal_code_regex     VARCHAR(255) NULL DEFAULT NULL

Затем используйте следующие списки для разработки таблицы вашей страны:

Вот анекдот для всех, кто наткнулся на этот вопрос:

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

Предоставьте три строки, в которые я введу один адрес. Передайте эти три строки в свой местный почтовый сервис, когда я их печатаю, дословно. Позвольте мне использовать любой набор символов, который я хочу; Используйте UTF-8 или что-то лучше.
Если в вашей системе есть бизнес -требования, которые необходимы для того, чтобы я указал конкретную информацию (например, почтовый индекс, префектура, состояние и т. Д.), Запрашивайте ее отдельно. Под бизнес -требованиями я имею в виду такие вещи, как аналитика; Эти кусочки информации не должны быть переданы вашей местной почтовой службе (если я также не оказался в одной и той же информации в одну из трех строк из точки 1 выше).
Имейте раскрывающееся список, который просит меня указать категорическое местоположение адреса, которое я предоставил в линии точки 1 выше, возможно, в стране.
Если вам необходимо проанализировать информацию, которую я предоставляет в строках точки 1, используйте мой ответ в точку 3, чтобы выбрать REGEX. Запустите эту форму против информации в пункте 1, чтобы проанализировать ее. Попробуйте заполнить элементы пользовательского интерфейса точки 2, используя вывод из вашей режима. Если я исправим эту автозаполненную информацию-используйте тот факт, что я изменил ее, чтобы улучшить вашу регуляцию. Точно так же, насколько это возможно, дайте мне возможность просмотреть и исправить вывод вашей режима: никто не знает лучше, что я намеревался общаться, чем я.

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

Если ваша фирма имеет внутренние знания о конкретных почтовых системах, используйте мой выбор в точке 3, чтобы сообщить, какое представление вы отображаете мне. Многие люди знают, чего ожидает почтовая система США на упаковке; Если я выберу нас в точке 3, не стесняйтесь сделать представление подходящим для адреса США. Если я выберу страну, о которой ваша фирма ничего не знает-разыгрываю общие три строки и позвольте мне сделать все остальное; Не заставляйте меня использовать ASCII.

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

Просто спроси Гёделя. (А затем спросите себя, пытаетесь ли вы использовать аксиоматическую систему, чтобы моделировать вселенную дискурса, дать или взять какую -то арифметику, подобную теории наборов или реляционной алгебры.)

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

AddressFormat (CountryCode, FieldName, Fieldorder)

Полевой порядок может быть закодирован для использования сложных сетей.

Нет смысла разделять адреса по стране. Это будет хаотично, так как число стран будет увеличиваться, и вы попадете в беду, если хотите найти все адреса, скажем, международного клиента. Наличие типа адреса, предложенного Беном, также может привести к неоднозначности, когда у вас есть адрес, который имеет как номер здания, так и номер квартиры. Я мог бы быть в жилом комплексе, где каждое здание имеет другое название. Это очень распространено в Индии.

я использую https://github.com/commerceguys/addressing Библиотека для форматирования международных адресов, и они используют эти элементы:

Country
Administrative area
Locality (City)
Dependent Locality (in: BR, CN, IR, MY, MX, NZ, PH, KR, ZA, TH)
Postal code
Sorting code
Address line 1
Address line 2
Organization
Recipient

Это не поможет, если вы хотите проанализировать улицу (имя, номер дома, ...).

Кстати. Если вы ищете список страновых страноводов: https://github.com/umpirsky/country-list

Единственный способ - разделить их на:

Name varchar,
Title varchar,
StreetAddress varchar,
StreetAddressLine2 varchar,
zipCode varchar,
City varchar,
Province varchar,
Country lookup

Поскольку почти у каждой страны есть свой собственный стандарт для получения адресных данных, а Evey Country имеет другой формат Zipcodes.
У вас может быть небольшая выборка проблем в мой пост Из аналогичного вопроса.

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

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

Я также видел несколько моделей, в которых просто была колонка «адрес», которая запечатлела типичный номер улицы, тип, название улицы, номер блока / квартиру и т. Д. Все в одном столбце, в то время как город, страна, регион и т. Д. В других столбцах. Аналогично модели Стивена, за исключением адреса1, адреса2 и адреса3 все объединены в один столбец.

Мое мнение таково, что наиболее гибкие модели, как правило, являются теми, которые являются наименее ограничительными, в зависимости от вашей интерпретации гибкой.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow