Распознавание строк

[jangle]

И чем же "улленинад26" лучше "ул ленина д 26"? Про знаки препинания вопросов нет.

Количество пробелов может быть разным, проще избавится от всех символов которые не несут полезной функции.
Да и в БД строки без пробелов займут меньше места, и при сравнении меньше процессорных тактов. Небольшая, но оптимизация.

[Antonariy]

Количество пробелов может быть разным,

Это типа проблема? Отцов русской демократии, знакомых с регэкспом, спасет паттерн \s{2,}, а незнакомые могут крутить в цикле

Код: Выделить всё

Replace(s, "  ", " ")

до тех пор, пока длина строки не перестанет уменьшаться.

которые не несут полезной функции

Пробелы разделяют смысловые единицы. Это бесполезная функция?

Да и в БД строки без пробелов займут меньше места, и при сравнении меньше процессорных тактов.

Экономика должна быть экономной
Будем экономить на спичках.

[qwertyhp]

jangle, несколько не так: если мы просто избавимся от разделителей, то запись вида
"ул.Ленина 11-2-132" после LCase превратится в кашу. Прежде сравнения придётся для каждой записи выяснить, где в ней улица (парсинг строки со сравнением по эталонному каталогу с попутной коррекцией очепяток), потом - какая часть записи больше подходит как дом, корпус и квартира (попутно всё найденное загоняется в массив), после чего кусочек массива, выделеный для этой записи, форматируется в какой-то предпочтительный для вас вид (например, "ул.Ленина 11-2-132" >>>"ул._Ленина,_д.11,_к.2,_кв.132"). И так для каждой записи. При этом приоритеты - как в жизни: улица-дом-квартира. Корпус может стоять по-умолчанию как 1-й и не записываться. Только после этого можно проводить сравнение адресов.
А вообще, можно сделать программку, в коей в качестве исходных данных были бы различные способы обозначения "дома" ("дом", "д.", "д", "число-" и т.д.) и т.п., - а программка комбинировала бы эти сокращения с числом всеми возможными способами, сохраняя результаты в файл: после чего можно вручную просмотреть этот комбинаторный маразм и отобрать из него всё то, что хоть как-то интерпретируется мозгом как адрес - и использовать отобранное в качестве эталонов для сравнения исходных записей (решета). В эталоне-то мы точно знаем, где дом, кв и тд.! А вместо номеров оставить дырочки одинакового размера. Отловили по эталону дом-к-кв - вставляем номера.

[jangle]

Количество пробелов может быть разным,

Это типа проблема?

Для меня не проблема, поэтому от них избавляюсь.

Пробелы разделяют смысловые единицы. Это бесполезная функция?

Что такое смысловые единицы? У меня есть БД с "эталонным" списком ужасного качества, который постоянно изменяется. И по вводу адреса, мне нужно вернуть ID записи в эталонном списке. Что там написано, оценить можешь сам. Заполняют его девочки-операторы, которым на все глубоко плевать

[Денис]

Jangle, тебе чтоли сложно признаться, что ты был неправ, решив удалить все пробелы? Зачем демагогию разводить?

[jangle]

Jangle, тебе чтоли сложно признаться, что ты был неправ, решив удалить все пробелы? Зачем демагогию разводить?

В чем я был неправ, удаляя пробелы? Можешь объяснить?

[Antonariy]

И по вводу адреса, мне нужно вернуть ID записи в эталонном списке.

Всего-то? Ради этого вообще не нужно трогать тексты, пусть операторы работают, а не ты.
По мере ввода адреса нужно отфильтровывать список, а оператор выберет из сузившегося списка подходящий адрес.

[Денис]

В чем я был неправ, удаляя пробелы? Можешь объяснить?

Объясняю, (хотя выше и так уже несколько раз объяснили):
Стирая пробелы между словами, ты превращаешь информацую из БД в кашу.

[Antonariy]

Для меня не проблема, поэтому от них избавляюсь.

Нет пробела — нет проблемы
Сталинская логика.

Стирая пробелы между словами, ты превращаешь информацую из БД в кашу.

+1
И как потом эту кашу представлять на обозрение юзерам? Вряд ли они обрадуются исчезнувшим пробелам, капсам и прочим кавычкам.

[jangle]

И по вводу адреса, мне нужно вернуть ID записи в эталонном списке.

Всего-то? Ради этого вообще не нужно трогать тексты, пусть операторы работают, а не ты.
По мере ввода адреса нужно отфильтровывать список, а оператор выберет из сузившегося списка подходящий адрес.

Операторы правят эталонный список, другие операторы вводят адрес чтобы получить ID из эталонного списка.
Проблема в том, что обе группы операторов хотя и придерживаются общих правил написания адреса, допускают ошибки. Например в эталонном списке есть: "Электроподстанция_ПС-110_№ 310_Свобода_" а оператор запращивающий адрес пишет " Электроподстанция ПС-110 № 310 Свобода "

Без удаления пробелов и символов _ сравнить эти две строки не получится

[Antonariy]

Зачем их сравнивать? Для этого:

И по вводу адреса, мне нужно вернуть ID записи в эталонном списке.

такое сравнение не нужно.
Для этого нужно сравнение Address like '%электроподстанция%ПС%110%310%Свобода%'. Или вообще '%электроподстанция%110%'. И попробуй доказать, что это не сработает.

[jangle]

В чем я был неправ, удаляя пробелы? Можешь объяснить?

Объясняю, (хотя выше и так уже несколько раз объяснили):
Стирая пробелы между словами, ты превращаешь информацую из БД в кашу.

И что из этого? По моему с самого начала шел разговор про промежуточный формат преобразования адресов.
Каша в БД роли не играет, юзер дает мне строковое название улицы, а в ответ должен получить числовой ID.
В каком виде хранится информация в БД ему глубоко паралельно

[jangle]

И попробуй доказать, что это не сработает.

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

[Antonariy]

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

А эту проблему, во-первых, как раз проще всего решить парой sql-запросов с update + replace, а во-вторых, это вообще не твоя проблема. Это проблема руководства, которое должно бить линейкой по пальцам тех операторов, кто косячит. На будущее же можно или запрещать ввод латиницы в поля, или проверять раскладку при вводе, выдавая соответствующее сообщение. И в-третьих, убиение пробелов эту проблему все равно не решит, ошибки в форматировании адреса и орфографические ошибки в словах — это разные ошибки.

[jangle]

А эту проблему, во-первых, как раз проще всего решить парой sql-запросов с update + replace,

А вот этого я не могу сделать организационно, из-за ограничений по информационной безопастности мне доступны только вызовы нескольких оракловских процедур. К самой БД меня никто не подпустит. Приходится все решать без SQL запросов.

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

Руководство считает по другому. И они правы человеческий фактор связанный с неправильным вводом адреса ликвидировать принципиально невозможно. Человек не робот, и всегда будет допускать ошибки. Поэтому его необходими минимизировать, хотябы на 20-30 процентов. Это уже удача.

На будущее же можно или запрещать ввод латиницы в поля, или проверять раскладку при вводе, выдавая соответствующее сообщение.

Увы это невозможно, слишком много организаций будет лезть со своими клиентами к этой базе.

[Antonariy]

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

Странно, а как же ты собирался уничтожать знаки препинания? Какие действия тебе вообще доступны? Перечисли.
Тебе нужно убедить начальство, что без дополнительных прав ты не сможешь решить поставленную задачу.

Руководство считает по другому.

Руководство не всегда право.

Увы это невозможно, слишком много организаций будет лезть со своими клиентами к этой базе.

Значить проблему с орфографией не решить в принципе. Плюс может появиться проблема с (не)умышленной порчей данных.

[qwertyhp]

Кажется, я что-то пропустил (отвлёкся на служебные обязанности). Когда мне пришлось приводить свою электронную библиотеку к одному виду, удаляя дубликаты и т.п., я поступил так: делал копию пытаемых файлов, из этих КОПИЙ удалял пробелы - и сравнивал копии. После чего, при совпадении, удалялся один оригинал и обе изуродованные копии. После чего снова делал копии оригиналов, и удалял из них ещё что-нибудь (гласные, знаки препинания, и т.п.). И снова сравнивал копии. Совпали - смерть одному оригиналу и обеим копиям. Но оригиналы ни в коем случае не модифицировались - а то потом их не узнаешь!
jangle, скажите, а есть ли статистика - какие ошибки наиболее типичны? В начале можно отлавливать именно их - путём подстановок/замен. Потом - приведение к одному виду слов типа "дом" (может писаться как "д.", "д", "д.,"), "квартира" ("кв", "кв.", "кварт", "кварт.", "к", просто цыфирьки, без букв), и т.п. А уже потом - разбирать (если они ещё останутся) конкретные глюки. Собственно, как при рассшифровке египетских письмён - устанавливаеются известные символы; ищутся похожие на известные и приводятся к виду известных; моделируется семантическая структура текста (с использованием известных элементов) на ново-египетском языке, и смотрим - а имеет ли эта фраза смысл?

[SLIM]

Вообще то Antonariy прав как никто другой, где-то полностью, где-то частично.
1. И в правду, как ты собрался исправлять все это без доступа в базу? Или ты собрался каждый раз проверять при очередном запросе ID? Не накладно будет?
2. Если руководство не хочет научить операторов делать правильно их работу, то лучше предложить руководству для данных операторов урезать возможность самовольничать, а конкретно, просто предоставить стандартный выбор ввода. Т.е. поля наименования улиц (или объектов) из базы, дом всегда как "д." и т.д. с контролем анти-латинского ввода.
3. Если все таки это невозможно, то нужно как-то подумать о то, как сам оператор, того не зная, обучает программу. Оператор так или иначе найдет тот косой адрес, и когда он его выберет, его запрос (изначально неверный, так как не совпадает с тем что в базе) занесется в список косых запросов, сопоставив их с правильным. Ну что-то типа этого.

А вообще, руководству надо менять подход...


UPD: А вообще,третий способ, это наверное самый фрикоспособ наверное.

[Roman Koff]

Я чтото не понял, а опреаторы инфу вводят в водре чтоди или ваще на бумажке ручкой?
Неужели нельзя сделать консоль ввода для операторов?

[qwertyhp]

Да, отлавливать ошибки на стадии ввода - это разумно. Например, при вводе названий УЛИЦ по мере изменения содержания текстового поля программа сама бы подставляла варианты продолжения, беря их из Базы (массива) (это несложно). Далее. Когда мне пришлось сталкнуться с задачей - вводить с бумажки колонки цифр по несколько в ряду - я сделал озвучку ввода: окончил ввод - программа проговаривает введённый текст, и есть возможеость исправить. К тому же, при использовании программы "перехвата ввода" есть возможность автоматическт форматировать текст по предпочтительному шаблону: "д" автопреобразуется в "дом", и т.п. Скакать по полям ввода тоже несложно. А вот анатомировать уже готовый текст... А-а, всё равно можно: только надо ВСЁ приедусмотреть. Например, что буква "Д" может означать не только "дом", но и быть частью названия улицы (ул. Дм. Ульянова), что может быть записано как "у Д Ульянова". Поэтому нужна проверка по Базе возможности появления одиноко стоящих буковок в названии улиц (предприятий, колхозов, и т.д.). Задача интерестная, решим.