Известно, что КЛАДР - не ахти какая дружелюбная штука. Поэтому чаще всего поле ADDRESS в таблице проектируется как обычное строковое поле достаточного размера. Также известно, что на забивке данных сидят люди, как правило, не самые грамотные и аккуратные.
И вместо адреса
357507, Ставропольский край, г. Пятигорск, ул. Ессентукская, д. 10а, кор. 2, кв. 1
может быть следующее:
СК, Пятигорск-7, Ессентукская 10а/2/1
Ставкрай, Пятигорск, Ессентукская ул, д.10-а, к2, кв1
гор. Пятигорск Ставропольского, ул.Ессентукская, 10а-2-1
Это не совсем патологические случаи. Причем сделано это было еще до того, как Вы устроились сюда на работу, то-есть, виновники уже уволились.
Наиболее вероятно, что наступит момент, когда адреса должны быть приведены в порядок. Когда проходит шок от этого известия, то
единственное, что приходит в голову - попытаться "пробить по кладру". Понятно, что кроме регулярных выражений тут мало что поможет.
Пробуем думать: отлавливаем с помощью RegExp примерно 10 последних знаков, начинающихся с пробела, это наверняка дом-квартира. Отбрасываем. Работаем с тем, что осталось. Допустим, что последнее самое длинное слово - это улица. Но ессентукских улиц даже в Ставропольском крае может быть до черта. А еще может быть станица Ессентукская, ул. 9 Мая... Получается, надо идти слева направо. А если там будет не край, а сразу город?
Остается уповать на то, что 90% прописаны именно в Ставрополье.
Кто-нибудь с этим сталкивался?
Оптимизация адресной базы данных
Re: Оптимизация адресной базы данных
Было такое дело. Решилось с помощью таблицы соответсвия и ручного проставление оного. За три часа было все сделано на базе из 300 тыс. абонентов.
Автоматизировать не получилось, потому что записаны адреса были черт знает как.
Автоматизировать не получилось, потому что записаны адреса были черт знает как.