Рекомендации по постоянному и всестороннему хранению адресов в базе данных

Существуют ли какие-либо передовые методы (или даже стандарты) для хранения адресов в последовательной и комплексной форме в базе данных?

Чтобы быть более конкретным, на данном этапе я считаю, что для хранения адресов есть два случая:

вам просто нужно связать адрес с человеком, зданием или любым предметом (наиболее распространенным случаем). Тогда, вероятно, достаточно плоской таблицы с текстовыми столбцами (address1, address2, zip, city). Меня это не интересует.
вы хотите запускать статистику по своим адресам: сколько предметов на определенной улице или в городе или... Затем вы хотите избежать орфографических ошибок любого рода и обеспечить согласованность. Мой вопрос касается лучших практик в этом конкретном случае: каковы наилучшие способы моделирования согласованной адресной базы данных?

Дизайн/решение для конкретной страны будет отличным началом.

ANSWER: пока не существует идеального ответа на этот вопрос, но:

xAL, как предложенный Хэнком, является самым близким к глобальный стандарт, который появился. Хотя, похоже, это слишком много, и я не уверен, что многие люди захотят реализовать его в своей базе данных...
Чтобы создать собственный дизайн (для определенной страны), ссылка Dave на Universal Почтовый союз (ВПС) - очень хорошая отправная точка.
Что касается Франции, для адресов есть норма (неофициальный, но де-факто стандарт), который носит прекрасное название AFNOR XP Z10-011 (только на французском языке), и за это нужно заплатить. Описание UPU для Франции основывается на этой норме.
Мне довелось найти эквивалентную норму для Швеции: SS 613401.
На европейском уровне были предприняты определенные усилия, в результате чего норма EN 14142-1. Он доступен через Национальные участники CEN.

Ответ 1

Я бы использовал таблицу Address, как вы предложили, и я бы основал ее на данных, отслеживаемых xAL.

Ответ 2

Я тоже об этом думал. Вот мои свободные мысли до сих пор, и мне интересно, что думают другие люди.

xAL (и его сестра, которая включает личные имена, XNAL) используется службами геокодирования Google и Yahoo, придавая ей некоторый вес. Но так как один и тот же адрес можно описать в xAL по-разному - более конкретный, чем другие, - тогда я не вижу, насколько xAL является приемлемым форматом для хранения данных. Однако некоторые из названий его полей могут быть использованы, но на самом деле единственным базовым форматом, который может использоваться среди 16 стран, к которым поставляется моя компания, является следующее:


enum address-fields 
{
    name,
    company-name,
    street-lines[], // up to 4 free-type street lines
    county/sublocality,
    city/town/district,
    state/province/region/territory,
    postal-code,
    country
}

Это достаточно легко отобразить в одну таблицу базы данных, просто разрешив NULL на большинстве столбцов. И похоже, что Amazon и многие организации фактически хранят адресные данные. Поэтому остается вопрос о том, как я должен моделировать это в объектной модели, которая легко используется программистами и любым графическим интерфейсом. У нас есть базовый тип Address с подклассами для каждого типа адреса, например AmericanAddress, CanadianAddress, GermanAddress и т.д.? Каждый из этих типов адресов будет знать, как отформатировать себя и, возможно, немного узнать о проверке полей.

Они также могут возвращать некоторые типы метаданных о каждом из полей, например следующую структуру данных псевдокода:


structure address-field-metadata 
{
    field-number,     // corresponds to the enumeration above
    field-index,      // the order in which the field is usually displayed
    field-name,       // a "localized" name; US == "State", CA == "Province", etc
    is-applicable,    // whether or not the field is even looked at / valid
    is-required,      // whether or not the field is required
    validation-regex, // an optional regex to apply against the field
    allowed-values[]  // an optional array of specific values the field can be set to
}

Фактически вместо индивидуальных адресов для каждой страны мы могли бы принять чуть менее объектно-ориентированный подход, когда объект Address избегает свойств .NET и использует AddressStrategy для определения правил форматирования и валидации


object address
{
    set-field(field-number, field-value),
    address-strategy
}

object address-strategy
{
    validate-field(field-number, field-value),
    cleanse-address(address),
    format-address(address, formatting-options)
}

При настройке поля этот объект Address будет ссылаться на соответствующий метод на свой внутренний объект AddressStrategy.

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

Вы можете представить, что процесс происходит примерно так:

GUI-код вызывает метод factory или некоторые из них для создания адреса на основе страны. (Таким образом, выпадающее меню страны - это первое, что выбирает клиент, или имеет хорошее предположение, предварительно выбранное для них на основе информации о культуре или IP-адресе.)
GUI вызывает address.GetMetadata() или аналогичный метод и получает список структур AddressFieldMetadata, как описано выше. Он может использовать эти метаданные для определения отображаемых полей (игнорируя те, у которых is-applicable установлен на false), что обозначать эти поля (с помощью члена field-name), отображать эти поля в определенном порядке и выполнять беглые, валидация уровня представления на этих данных (с использованием членов is-required, validation-regex и allowed-values).
GUI вызывает метод address.SetField(), используя field-number (что соответствует перечислению выше) и его заданным значениям. Объект Address или его стратегия могут затем выполнить некоторую расширенную проверку адреса в этих полях, вызвать очистители адресов и т.д.

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

Есть ли в этом смысл? Я слишком далеко отклонился от пути ООП? Для меня это представляет собой довольно разумный компромисс между тем, чтобы быть настолько абстрактным, что реализация почти невозможна (xAL) по сравнению с тем, что она строго ориентирована на США.

Обновление через 2 года: В конце концов я получил систему, подобную этой, и написал об этом в мой несуществующий блог.

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

Ответ 3

В Великобритании есть продукт под названием PAF от Royal Mail

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

Ответ 4

В основном я вижу 2 варианта, если вы хотите согласованности:

Очистка данных
Таблица основных данных выглядит вверх

Объявление 1. Я работаю с SAS System, а SAS Institute предлагает инструмент для очистки данных - это в основном выполняет некоторые проверки и проверки ваших данных и предполагает, что "Abram Lincoln Road" и "Abraham Lincoln Road" будут объединены на той же улице. Я также думаю, что он опирается на национальные базы данных, содержащие совпадения между городом и почтовым индексом и т.д.

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

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

Ответ 5

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

См. веб-сайт Всемирного почтового союза для получения очень подробной и подробной информации о форматах международных почтовых адресов: http://www.upu.int/post_code/en/postal_addressing_systems_member_countries.shtml

Ответ 6

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

Это не важный аргумент. Реализация адресов не является тривиальной задачей, если система должна быть "всеобъемлющей и последовательной" (т.е. Во всем мире). Реализация такого стандарта действительно требует много времени, но для выполнения указанного требования все же обязательна.

Ответ 7

нормализовать схему базы данных, и у вас будет идеальная структура для правильной согласованности. и именно поэтому: http://weblogs.sqlteam.com/mladenp/archive/2008/09/17/Normalization-for-databases-is-like-Dependency-Injection-for-code.aspx

Ответ 8

Я спросил что-то очень похожее ранее: Динамические данные контактной информации/шаблон дизайна: возможно ли это?.

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

Ответ 9

В США я бы предложил выбрать National Change of Address vendor и создать модель DB после того, что они вернут.

Ответ 10

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

www.upu.int имеет стандарты формата для международных адресов. Публикация 28 на usps.com имеет стандарты формата США. CASS, например http://semaphorecorp.com делает валидацию для адресов в США.