Лучшие практики для последовательного и всеобъемлющего хранения адресов в базе данных

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

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

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

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

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

1. Очистка данных
2. Поиск в таблице основных данных

Объявление 1. Я работаю с системой SAS, и институт SAS предлагает инструмент для очистки данных - он в основном выполняет некоторые проверки и проверки ваших данных и предлагает объединить «Аврам Линкольн Роуд» и «Авраам Линкольн Роуд» в одно и то же улица. Я также думаю, что он основан на национальных базах данных, содержащих совпадения почтовых индексов и так далее.

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

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

I asked something quite similar earlier: Динамические данные контактной информации / шаблон дизайна: возможно ли это каким-либо образом?.

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

В США я бы предложил выбрать национального поставщика смены адреса и смоделировать БД после того, как они вернутся.

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

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

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

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(), а не свойств с геттерами и сеттерами, заключается в том, что для кода проще фактически установить эти поля универсальным способом, не прибегая к операторам отражения или переключения.

Вы можете представить себе этот процесс примерно так:

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

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

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

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

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

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

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