Ответ 1
Способ приближения к этой проблеме может быть следующим:
принять три вида адресов/телефонных номеров/почтовых кодов и т.д.
-
Первое представление относится к адресам (скажем) как к нескольким строкам текста.
-
Второе представление - это теги адресов (подробнее об этом ниже).
-
Третье представление - это правила проверки адресов для адресов
Другими компонентами, которые необходимы для этого подхода, являются общая процедура (класс/триггер) для проверки; процедура форматирования для целей печати; и базу правил вместе с механизмом администраторов для обновления правил проверки. Правило "catchall", которое говорит об этом, является допустимым адресом - оно проверено вручную - даже если оно не отвечает ни одному из правил вашей базы правил.
Компоненты: 1 Адрес состоит из нескольких строк, каждый из которых имеет связанный порядковый номер и несколько тегов (обычно один). Можно также связать с адресной строкой, набором правил и версиями правил, с которыми они были проверены, но это уточнение, которое зависит от ваших скоростей обновления/вставки/расчета.
2 Тегами адресов являются такие вещи, как город; город; номер дома; и идентифицировать разные строки адреса. Возможно иметь адресную строку, которая не имеет никаких тегов, но в этом случае возможны только общие поисковые запросы (например, для Нью-Йорка) на полном наборе строк. Поиски "City = New York" ) невозможны.
3 Правила, написанные на определенном домене. Это может быть регулярное выражение; язык, специфичный для вас; ваш нормальный язык разработки (хотя это, вероятно, будет наименее полезным подходом, поскольку языкам программирования может быть сложно понять и точно представить правила, о которых я говорю. Пример типичных правил может быть (касающийся вашего описания US Zip Codes) - первые пять символов должны быть цифрами.
первые пять символов представляют собой "код зоны".
почтовый индекс должен быть последней строкой адреса.
Правила будут разделены на группы и наборы (например, адреса США). Правила должны иметь возможность ссылаться на другие правила, а также на адресные данные.
-
Ваша процедура проверки должна принимать строки адреса и применять к нему правила (обычно по набору). Он вернет логический - допустимый или недействительный адрес и, возможно, набор правил, которые он проверял.
-
Процедура печати снова применит соответствующий набор правил (возможно, отличный от вашего набора проверки) к данным адреса, чтобы обеспечить отформатированный адрес.
Я надеюсь, что другие компоненты будут очевидны из общего подхода.
Этот подход предназначен для решения этих проблем, определенных в вашем вопросе:
-
Разделение телефонных кодов.
-
Ограниченное количество возможных кодов областей.
-
Блоки телефонных номеров, зарезервированные для определенных целей.
-
Нормализация данных - данные нормализованы. Однако этот тип нормализации (обратная индексация) обычно не используется, за исключением программного обеспечения хранилища данных и баз данных, содержащих массивные данные датчика в реальном времени. Возможно, что при внедрении этого решения вы можете выбрать дублирующиеся данные (контролируемые). Это не является неотъемлемой частью решения, но может быть удобным.
-
Я бы настоятельно рекомендовал НЕ добавлять классы для каждого варианта - это не масштабируемо и не поддерживается.
-
Поиск подробно описан ниже.
-
Таблицы монстров избегаются: база правил, вероятно, будет или порядок от сотен до нескольких тысяч правил, дополняющих фактические данные.
-
Решение является масштабируемым - одно просто добавляет или изменяет правила.
а также справиться с некоторыми связанными проблемами.
-
Даже если вы можете применять правила валидации к национальным форматам адресов, всегда будут исключения из стандартов для конкретной страны. Мой собственный адрес - пример - я живу на лодке и нуждаюсь в дополнительной информации, включенной в мой адрес, помимо стандартного адреса почтового ветки. Аномалии такого рода всегда, вероятно, нуждаются в ручном вмешательстве - отсюда правило, принятое ручным вмешательством.
-
В разных странах разные адреса для адресов - адреса в Китае, например, написаны: Страна; Почтовый индекс; Город; Городская зона; Название улицы; Номер дома; Имя человека.
-
Принятие первого адреса из области, где у вас нет правил, а правила страны отличаются от всех, которые вы записали.
-
Люди, которые хотят использовать (например, офис) адрес, отличный от "своего" адреса.
-
Конкретные проблемы с индивидуальной адресацией - кто-то, кто хочет скрыть свою переписку от ближайших и самых близких.
-
Решение может быть распространено на подобные проблемы - например, обращение к человеку. Это может включать заголовки - 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 в таблице адресной строки является его первичным ключом.
Когда речь идет о более подробных ресурсах для этой концепции, у меня есть две проблемы.
Первый (и тривиальный) заключается в том, что эта концепция - моя оригинальная работа, основанная на моем опыте более двадцати лет в качестве консультанта по методу и консультанта по ИТ-стратегии с особым интересом к технологиям среды разработки и методам разработки. Вся моя трудовая жизнь была проведена в средах, где контактная информация была главной проблемой (по финансовым и нормативным/законодательным причинам). На самом деле мой первоначальный ответ на ваш вопрос был полным в моем сознании, прежде чем я закончил читать ваш вопрос, хотя это и произошло, и потребовалось около трех четвертей часа, чтобы набрать его.
Более важная причина заключается в том, что некоторые источники этой идеи являются конфиденциальными или секретными. В моей рабочей карьере часть моей работы заключалась в том, чтобы следить за развитием технологий и прогнозировать влияние технологий на бизнес через десять лет. Это включало посещение исследовательских лабораторий и обсуждение с ведущими исследователями по различным темам. В то время как я, я, исследователь первого класса, я, кажется, очень хорошо разбираю усилия других исследователей. Однако, делая это, я всегда работал в условиях коммерческой конфиденциальности и/или военной тайны. Ни один из моих ответов не нарушил эти условия. В результате этого я могу лишь дать неопределенные указания относительно того, как была получена информация.
Мои источники:
-
семинар, проведенный 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.