Лучшие практики для последовательного и всестороннего устройства хранения данных адреса в [закрытой] базе данных

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

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
}

Это достаточно легко отобразить в таблицу единой базы данных, просто обеспечение АННУЛИРУЕТ на большинстве столбцов. И кажется, что это - то, как Amazon и много организаций на самом деле хранят адресные сведения. Таким образом, вопрос, который остается, состоит в том, как я должен смоделировать это в объектной модели, которая легко используется программистами и каким-либо кодом GUI. У нас есть основа 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() подход метода, а не свойства с методами get и методами set состоит в том так, чтобы для кода было легче на самом деле установить эти поля универсальным способом, не обращаясь к отражательным или операторам переключения.

можно вообразить процесс проходящим примерно так:

1. код GUI называет метод фабрики или некоторых таким для создания адреса на основе страны. (Выпадающая страна, тогда, является первой вещью, которую клиент выбирает или предварительно выбрал хорошее предположение для них на основе информации о культуре или IP-адреса.)
2. вызовы GUI address.GetMetadata() или похожий метод и получает список эти AddressFieldMetadata структуры, как описано выше. Это может использовать эти метаданные для определения, какие поля отобразить (игнорирующий тех с [1 114] набор к [1 115]), что маркировать те поля (использующий field-name участник), отобразить те поля в особом порядке и выполнить поверхностную проверку уровня представления на тех данных (использующий is-required, validation-regex, и allowed-values участники).
3. GUI звонит address.SetField() метод с помощью field-number (который соответствует перечислению выше), и его данные значения. Эти Address объект или его стратегия могут тогда выполнить некоторую усовершенствованную проверку адреса на тех полях, вызвать инструменты для очистки адреса, и т.д.

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

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

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

В Великобритании существует продукт, названный PAF от Королевской Почты

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

Я в основном вижу 2 варианта, если Вы хотите непротиворечивость:

1. Данные, чистящие
2. взлеты взгляда таблицы Основных данных

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

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

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

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

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

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

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

короткий ответ: Хранение adderres или любой вид контактной информации в базе данных сложны. Растяжимый Язык Адреса (xAL) ссылка выше имеет некоторую интересную информацию, которая является самой близкой к стандарту/лучшей практике, через который я приехал...

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