ИМХО, поставленная ЗАКАЗЧЕГОМ задача из разряда: "напиши мне искусственный интеллект", которую ТС зачем-то пытается решить. а всё от неправильного (или непредусмотренного функционалом) проектирования базы на стадии первого внедрения.

к примеру, на стадии внедрения для поля "адрес контрагента" предусматривается 255 символов, в которые операторы вколачивают всё, что бог на душу положит. вот вы знаете, как можно написать на слух улицу им.Кржижановского?
внимание!!! опасно для мозка!!


потом ЗАКАЗЧЕГ открывает для себя гугл-мапс и хочет "покрытие" клиентами на карте. для чего, естественно, ему нужно, чтобы адрес хранился уже в виде набора полей:
1) ID_TOWN
2) ID_STREET
3) HOUSE
4) CAB

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

вопрос: а шо делать со старыми 27000 контрагентов?
и тут уж пусть решает заказчег из следующего набора вариантов:
а) "с завтрашнего дня живём по новому."
б) "мне старые 27000 контрагентов дороги, как память." как оперативная память.

тогда:
б.1) мы конечно поможем и скриптом по подстроке попытаемся обработать адреса контрагентов в базе с целью забить автоматически в новом формате. из 27000 приблизительно 18500 лягут в базу как надо.
б.2) ЗАКАЗЧЕГ нанимает абизяну (мы её специально обучим), которая перепроверит все адреса в базе. месяца за три.

-----------
обратите внимание: либо валидацией данных занимаются homo-sapines, либо старые данные принимаются "как есть".

а написание искусственного интеллекта - это не сюда.
хотя, можно и сюда, но уже за ДРУГИЕ деньги.

-----------
но всё вышеизложенное - полная фигня.
жизнь гораздо интереснее!
к примеру, когда после валидации данных абизяной начинается компания по массовому переименованию улиц. тут конечно всё просто: - добавляем в таблицу STREETS поле NEW_NAME.
но зато какие интересные логические коллизии при этом возникают! к примеру, распечатать договор по состоянию на 01 марта 2014 года. =)

Andrey_PEAKTOPк примеру, распечатать договор по состоянию на 01 марта 2014 года. =)А для таких вещей изобретено, что все итоговые документы хранятся не только со ссылками на на Id из справочника, но и со значениями

ладно, согласен, пример неудачный.

более близкий пример к парсингу стрингов с адресами и попытке написать "искусственный интеллект".
как было сказано ранее, из 27000 адресов 18500 легли, как надо.
вопрос: а шо же не так с оставшимися 8500 адресами?

да, безусловно, в базе были грамматические ошибки. это - таки да, не знаю сколько, но где-то на глазок около 10..15% от 8500 штук.
а оставшиеся... вот тут интересно: адреса были в формате "г.Краматорск, ул.Ленина, д.-1, кв.-1" или "г.Славянск, ул.Юных Коммунаров, д.-1, кв.-1". но!

в городе Краматорске есть:
1) бульвар Краматорский, расположен самом густонаселённом спальном районе
2) улица Славянская
3) переулок Славянский

в городе Славянск есть:
1) улица Краматорская

оператор ввода вполне может пропустить в адресе "ул." или "бул."

а теперь, уважаемые знатоки, внимание, вопрос: и как писать парсер для таких случаев? =)

----------
специально обученная абизяна справляется с этим за три месяца вручную.
но это 1) проблемы ЗАКАЗЧЕГА и 2) за деньги ЗАКАЗЧЕГА.

WildSeryPEAKTOP,

Прекращай уже слова коверкать.

ЗАКАЗЧЕГ - это сложившееся (среди IT в нашей местности) обезличенное название предприятия/компании заказчика.
как говорится, "без имен и званий".

просто, есть ЗАКАЗЧЕГ, который платит деньги и заказывает музыку. о чём идет речь - все понимают и заодно не уточняют, как зовут, кто такой.
если бы я хотел - сказал бы прямо "ООО СтройПромТоргВсё", а так... ЗАКАЗЧЕГ. то есть никто.

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