Вообщем-то не знаю в какой раздел лучше это пихнуть, но вопрос такой:

В логах от "железки" номера(телефонные) могут приходить в таких видах как 78432993040 или 88432993040 или 2993040 или 993040...... Вот мне и нужно выцеплять такие номера, точнее сказать проверять другую информацию, по номерам, которая пишется в логах......
Изначально я просто все задумал, завел таблицу в БД, прописал самый длинный вариант номера
и запрос был таков, часть запроса:

(скрипт на перле написан, на всякий случай) но тут не суть важно к какому именно языку принадлежит код  

Но вылезла такая проблема, что встречаются подобные номера 11(это номер телефона с которого звонят) а в базе у меня есть номер 78432993011(но это не одно и то же лицо), но в итоге у меня будет выглядеть как одно и тоже, потому как по запросу будет проходить, и боюсь это не еденичный случай...... Вот только я не знаю как мне этого избежать, дублировать в базе все номера по тому виду в каком он может прийти в логах, то бишь по одному и тому же клиенту писать четыре раза
78432993011
88432993011
2993011
993011

и потом


или...... вот другое или мне пока в голову не приходит  

И кстати нагружать код, громоздким анализом пришедшего номера не хотелось бы  

Разбей номер на элементы, т.е. код выхода на межгород, код города, первая цифра номера, оставшиеся цифры номера. Например номер 78432993011 будет разбит так: 7 | 843 | 2 | 993011, а номер 2993011 так: null | null | 2 | 993011. А затем номер который надо найти разбиваешь на такие же элементы и ищешь его. И главное тут не будет никаких like.

like рессурсов много кушает.

А если звонок будет с 5-ти цифровой АТС или  код города будет 4-х значным? Т.е. нужно проверять на длину номера: 
 ... and len(source_info) = ....

Да хоть с 3-х значной. В одном городе номера имеют одинаковую длинну. И значит если номера одинаковые, то у них и длинна одинаковая.
Единственное, я не понял почему первая цифра в номере может быть отброшена, а так длинна номера тут не важна.

в одном городе - да (и то не всегда), но есть еще и междугородние и международные звонки

И что? Из номера можно выделить: код выхода на междугороднюю связь, код города, номер телефона. Пусть даже в одном городе есть номера с разной длинной, мы все равно будем сравнивать номера целиком. Номер 11 и 993011 не равны, ни при каком раскладе.

интересно, каким образом ты собираешься идентифицировать из сплошной цепочки цифр номера коды страны или города?


Читай начальное условие:


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

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


Читай мое предложение:

Не будет тут уже никаких "длинных" номеров. Номер будет состоять из компонент, и полные номера никто не будет сравнивать.
А LIKE это зло  

Если бы речь о Firebird шла, можно было бы свою UDF написать на С.

Вариант сразу отбрасывается, потому как нагружать такими вещами, конечно правильно спрофессиональной точки зрения, однако не целесообразно, по ряду других причин  

с междугородкой и международными звонками проблем-то не будет, мне нужно лишь четко определять те звонки, номера которых есть в БД, то бишь наших клиентов, все остальное, ну я не думаю что будут сложности  

т.е. ты предлагаешь, банально, разбить на состовляющие и по состовляющим сравнивать весь номер, соответственно........ или что-то более хитрое?  

Именно. По скорости выборки это будет самое быстрое решение.