Способ решения этой проблемы может быть следующим:
принять три представления адресов / телефонных номеров / почтовых индексов и т. Д.
Первое представление - это представление адресов(скажем) в виде нескольких строк текста.
Второй вид - это адресные теги (подробнее об этом ниже).
Третье представление - это правила проверки адресов
Другие компоненты, необходимые для этого подхода, являются общей процедурой (класс /триггер) для проверки;процедура форматирования для печати;и база правил вместе с механизмом администраторов для обновления правил проверки.Правило «catchall», которое говорит, что это действительный адрес - он был проверен вручную - даже если он не соответствует ни одному из правил вашей базы правил.
Компоненты: 1 Адрес состоит из нескольких строк каждаяиз которых есть связанный порядковый номер и количество тегов (обычно один).Можно также связать с адресной строкой набор правил и версий правил, по которым они были проверены, но это уточнение, которое зависит от ваших скоростей обновления / вставки / расчета.
2 Адрестеги - это как город;городок;номер дома;и определить разные строки адреса.Возможно иметь адресную строку, которая не имеет каких-либо тегов, но в этом случае возможны только общие поиски (например, для Нью-Йорка) по полному набору строк.Поиск "City = New York") невозможен.
3 Правила написаны на языке, специфичном для домена.Это может быть регулярное выражение;специфический для вас язык;Ваш обычный язык разработки (хотя это, вероятно, наименее полезный подход, поскольку языкам программирования может быть трудно точно и точно представлять правила того типа, о котором я говорю. Пример репрезентативных правил может быть (в связи с вашим описаниемПочтовые индексы США) - первые пять символов должны состоять из цифр.
первые пять символов представляют «код города».
почтовый индекс должен быть последней строкой адреса.
Правила будут разделены на группы и наборы (например, адреса США). Правила должны иметь возможность ссылаться на другие правила, а также на данные адреса.
Ваши потребности в проверке правильностивзять строки адреса и применить к нему правила (обычно с помощью набора). Он вернет логический - действительный или недействительный адрес и, необязательно, набор правил, с которыми он проверен.
Процедура печати снова применит соответствующий набор правил (возможно, отличный от вашего набора проверки) кданные адреса для предоставления отформатированного адреса.
Я надеюсь, что другие компоненты очевидны из общего подхода.
Этот подход предназначен для решения этих проблем, определенных в вашемвопрос:
Разделение телефонных кодов.
Ограниченное количество возможных используемых кодов города.
Блоки телефонных номеров, зарезервированных для определенных целей.
Нормализация данных - данные нормализуются.Однако этот тип нормализации (обратная индексация) обычно не используется, за исключением программного обеспечения хранилища данных и баз данных, содержащих массивную информацию датчиков в режиме реального времени.Возможно, что при реализации этого решения вы можете выбрать (контролируемо) дублирование данных.Это не является неотъемлемой частью решения, но может быть удобным.
Я настоятельно рекомендую НЕ добавлять классы для каждого варианта - это не масштабируется и не поддерживается.
Поиск подробно описан ниже.
Избегайте таблиц монстров - скорее всего, будет база правил или порядка сотен или менее тысяч правил.к фактическим данным.
Решение является масштабируемым - можно просто добавить или изменить правила.
, а также решить некоторые связанные с этим проблемы.
Даже если вы можете применять правила проверки к национальным форматам адресов, всегда будут исключения из стандартов для конкретной страны. Мой собственный адрес является примером - я живу на лодке, и мне нужна дополнительная информация, включенная в мой адрес, помимо стандартного адреса почтового отделения. Подобные аномалии всегда могут нуждаться в ручном вмешательстве - следовательно, это правило принимается ручным вмешательством.
В разных странах разные порядки адресов - например, в Китае пишутся адреса: Страна; Почтовый индекс; Город; Городская зона; Название улицы; Номер дома; Имя человека.
Принятие первого адреса из области, в которой у вас нет правил, и правила страны отличаются от тех, которые вы записали.
Люди, желающие использовать (например, офис) адрес, отличный от «своего» адреса.
Конкретные индивидуальные адресные проблемы - кто-то, желающий скрыть свою переписку от своих родных и близких.
Решение может быть распространено на подобные проблемы - например, обращение к человеку. Это может включать названия - Dr, Rev и т.д .; множественные дефисные имена (ffoulkes-symthe); квалификации (CPA, BSc и т. д .; семейные квалификации (третий и т. д.), а также различные способы присвоения имен в зависимости от культуры личности (люди на индийском субконтиненте часто не имеют фамилии, и у каждого, очевидно, будет своя фамилия ).
Изменения в правилах адресации (например, добавление нового почтового индекса для новой разработки) могут быть сделаны легко и быстро.
Проблемы, которые все еще возникают:
Поиск будет несколько более сложным - требуется поиск по всем строкам и связанным тегам адресов, а не по конкретным адресным полям
Требуется время, чтобы создать базу правил такого рода - хотя начальная загрузка правил может быть выполнена довольно быстро - примеры присутствуют в вашем вопросе - что-то вроде полного набора будет присутствовать только после того, как вы разберетесь множественные исключения и аномалии.
EDIT:
Я не знал о BigTable, когда писал свой ответ. После очень быстрого взгляда на это, похоже, это очень похожая концепция. Что касается его реализации в разработке ACID, я думаю, что это возможно для контактного набора данных и для базы данных правил. Из своего опыта я знаю, что он легко масштабируется до 5 * 10 ^ 7 наборов контактных данных в такой среде (хотя с фоновой, не критичной ко времени проверкой контактных данных).
При рассмотрении случая ACID / SQL моё использование слова «представление», возможно, привело к тому, что заяц ушел в направлении, которое я не намеревался. Более подходящим словом может быть обзор или перспектива (что-то без реляционной модели или прикрепленной загрузки СУБД). Фактически я бы рассматривал каждую из вещей, которые я назвал представлением, как таблицу кандидатов.
Я изложил эскиз схемы для моего подхода, чтобы помочь обсуждению. Эта схема использует некоторые соединения M: N, которые, очевидно, были бы нормализованы в реализации в виде ассоциативных таблиц. Это оставлено в качестве упражнения для читателя :-). Я поместил несколько примеров атрибутов и данных в некоторые из таблиц.
В эскизе редактирование набора правил; Правило; и правила, относящиеся к другим правилам (административное приложение), очевидно, могут быть выполнены со свойствами ACID с помощью операций SQL Normal CRUD над пользователем адреса; Адрес; и Адресная строка также может быть выполнена способом ACID / SQL, принимая адресные строки как вводимые пользователем. Вы можете выполнить некоторую предварительную обработку транзакции, чтобы отделить (в моем примере) номер дома от названия дороги и, следовательно, потерять правило «название дороги». Другая предварительная обработка, которая, вероятно, будет полезна, - это стандартизация капитализации, хотя это также может быть частью этапа проверки. Также можно просто принять полную строку «9 Richmond Road» в качестве входных данных и отметить ее как «Требуется проверка». В любом случае нет проблем (о которых я знаю) в отношении этой транзакции ACID.
Где мне не совсем понятно, как проверка и последующие теги могут быть включены в транзакцию ACID / SQL. Похоже, что для выполнения шага проверки ACID может потребоваться упорядочить применение тестирования по наборам правил (сначала проверяются наиболее распространенные случаи и прекращается при успешной проверке). Кроме того, для проверки транзакции ACID может потребоваться проверка только по вашему наиболее распространенному случаю, при этом остальные будут помечены как «Требуется проверка», что затем будет выполнено в качестве фоновой задачи.
Фактическая задача проверки включает проверку всей базы правил, заданной набором, до тех пор, пока не будет найден набор правил, который проверяет все входные строки. Очевидно, есть потенциальные ориентиры для самих данных - если вы записали страну, то это позволяет вам сразу пометить строку со страной, и предоставляет фильтр для наборов правил, с которыми вы должны проверять. Я извиняюсь, но это настолько далеко, насколько я могу взять этот аспект до сих пор.
Между прочим, эта схема эскиза идет лишь частично к полной нормализации. Как показано, каждый адрес имеет свою собственную последовательность адресных линий, и нет никакой нормализации данных за пределами отдельных строк в качестве входных данных (плюс или минус любая предварительная обработка, которую вы выбираете делать). Можно пойти еще дальше - сделав связь между адресом и адресной линией M: N и убедившись, что поле Line таблицы Address Line является ее первичным ключом.
Когда речь идет о более подробных ресурсах для этой концепции, у меня есть две проблемы.
Первый (и тривиальный) из них заключается в том, что эта концепция - моя оригинальная работа, основанная на моем более чем двадцатилетнем опыте работы консультантом по методам и консультантом по ИТ-стратегии с особым интересом к технологиям среды разработки и методам разработки. Вся моя трудовая жизнь была проведена в среде, где контактные данные были серьезной проблемой (по финансовым и нормативным / законодательным причинам). Фактически, мой первоначальный ответ на ваш вопрос был полным в моей памяти, прежде чем я закончил читать ваш вопрос, хотя мне потребовалось около трех четвертей часа, чтобы его напечатать.
Более важной причиной является то, что некоторые из источников этой идеи являются конфиденциальными или секретными. В моей рабочей карьере часть моей работы заключалась в том, чтобы быть в курсе технологических разработок и прогнозировать влияние технологий на бизнес через десять лет. Это включало посещение исследовательских лабораторий и обсуждение с ведущими исследователями различных тем. Хотя я сам не являюсь первоклассным исследователем, я, похоже, очень хорошо синтезирую исследовательские усилия других. Тем не менее, при этом я всегда работал в условиях коммерческой конфиденциальности и / или военной тайны. Ни один из моих ответов не нарушил эти условия. В результате я могу дать лишь расплывчатые указания относительно того, как была получена информация.
Мои источники:
семинар, проведенный C J Date в IBM, для изучения дальнейших достижений нормализации и реляционной модели (НЕ реляционной модели, реализованной в SQL). Это включало исследование пятой (?) И шестой (?) Нормальных форм.
серия обсуждений с техническим персоналом Oracle в течение определенного периода времени, обсуждение метаданных; мета-метаданные; и другие подобные обобщения.
переговоры с военным научно-исследовательским учреждением в Великобритании. Хотя это было несколько лет назад, я не уверен, было ли что-либо опубликовано по темам, которые мы обсуждали.
работа в крупном финансовом учреждении, система контактных данных которого была очень похожа на мое предложение, но возникла из нереляционных корней; и для которого первоначальным техническим стимулом была экономия места в эпоху, когда память, постоянная память и резервная емкость были главной проблемой.
EDIT:
Я завершил вышеописанное редактирование, закрыл свой компьютер, выполнил некоторые домашние дела, лег спать, лежал, закрыл глаза, и у меня было решение той части, которую я не мог выполнить в предыдущем редакторе.
В то время как есть обновления, которые нужно сделать, чтобы пометить / проверить правильность, большая часть работы - это чтение и сравнение. Как таковой, он является главным кандидатом на оптимистическую блокировку. В псевдокоде это будет выглядеть так:
Start read transaction
Read set of address lines where one or more lines are "Needs Validation"
Read all rule set names
Read all rule lines which belong to the first rule set
If read is not successful then abandon and start process again
End read transaction
Do while address not validated and not end of rule sets
If set of address lines validates against first rule set then
prepare transaction by allocating the tags to be applied to each line of the
address and temporarily recording the rule set that has validated the address
Start validation transaction
Read same set of address lines and rule set (all fields)
Is the address and the rule set identical to what was obtained in the read
transaction?
If identical then
create appropriate set of Tag Usage records
if successful then
commit validation transaction
end overall process
if not successful or
if not identical then
rollback validation Tag and Tag Usage
** This is the point where there might be problems if the rule set has
changed since reading it. The ordering may have changed due to amendment
deletion or creation of rule sets. This is the reason for the read of all
the read set names initially. However if there is such a change one can
afford to fail to validate and move on, aiming to come back to this address
later.
End of validation transaction
Start read transaction
Read rule lines which belong to the next rule set
End read transaction
End while loop
If end of rule sets reached and address not validated
begin create Tag Usage transaction
create tag usage pointing to Tag "Manual Intervention needed"
end create Tag Usage transaction
Все три типа транзакции (адрес, обновления адресной строки, набор правил, обновления правил и обновления тегов, использования тегов) соответствуют условиям ACID. Я твердо верю (но не доказал), что любой чередующийся, комбинированный или пересекающийся набор этих трех типов транзакций также будет удовлетворять условиям ACID.