2010-07-23 3 views
5

Мое приложение хочет сохранить список международный номер телефона в базе данных mysql. Затем приложение должно будет запросить базу данных и выполнить поиск определенного номера. Звучит просто, но на самом деле это огромная проблема.Борьба с базой данных MySQL по телефонам

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

Например. У нас может быть номер 17162225555, хранящийся в базе данных (вместе с еще 5 миллионами записей). Теперь пользователь приходит и пытается выполнить поиск с использованием 7162225555. Другой пользователь может попробовать serach с 2225555. и т. Д. Иными словами, база данных должна выдать SQL-запрос, используя «как% number%», что приведет к полное сканирование.

Как мы должны проектировать это приложение? Есть ли способ потренировать Mysql, чтобы справиться с этим лучше? Или мы вообще не должны использовать SQL?

PS. У нас есть миллионы записей и 10 с этих поисковых запросов в секунду.

+0

Не могли бы вы создать приложение для ввода определенных полей, а затем сломать номер. И.Е. код страны, 7-значный номер и т. д. Затем вы сопоставляетесь с индексированным столбцом, а не с полным текстовым поиском. – JNK

+0

Вы только сохраняете номера в Соединенных Штатах, или у вас есть международные номера? Если это всего лишь номера в США, следует легко форматировать номера, как предлагает JNK. Если вы используете международные номера, я подозреваю, что это будет намного сложнее. –

+0

Этот связанный вопрос обсуждает разбиение международных номеров на составные части, если это так, как вы хотели перейти http://stackoverflow.com/questions/2543938/how-to-split-mobile-number-into-country-code -area-code-and-local-number/2544066 # 2544066 –

ответ

8

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

Возможно, вы создали отдельное поле с именем reverse_phone_number, которое автоматически заполняется механизмом БД, а затем, когда люди ищут, просто отменяют строку поиска и используют индексированное обратное поле только с% в конце строки, тем самым позволяя использование индекса.

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

В некоторых странах, например, в Великобритании у вас может возникнуть проблема с ведущими нулями. Телефонный номер Великобритании представлен как (код зоны) (номер телефона), например. 01634 511098, когда это интернационализировано, удаляется ведущий нуль кода зоны и добавляется международный код набора (+ или 00) и код страны (44). Это приводит к международному номеру телефона +441634511098. Любой пользователь, который ищет 0163451109, не найдет номер телефона, если он был введен в международном формате. Вы можете преодолеть эту проблему, удалив ведущие нули из строки поиска.

EDIT На основе предложений Олли Джонс, вы должны сохранить номер, введенный пользователем, а затем раздеться ведущие нули, знаки препинания и пробелы из числа перед разворотом и хранения в обратном поле. Затем просто используйте тот же алгоритм, чтобы разбить строку поиска перед реверсированием, найти запись и затем отобразить первоначально введенный номер обратно пользователю.

+0

Steve, что обратное # поле - гений. – JNK

+0

Чтобы убедиться, что я понял, что вы имеете в виду, у вас будет вторая таблица, в которой хранятся все их запросы, с таблицей моста, соответствующей телефонным номерам, которые она привела? Автоматически заполняется для каждого нового запроса, поэтому, если кто-то войдет в существующий поиск, он просто посмотрит на старые результаты? Прекрасная идея. – Tarka

+1

doh! вы избили меня на несколько секунд. Я думаю, что поле reverse_phone_number является очень хорошим решением, если мы можем предположить, что пользователь всегда будет знать последние цифры номера телефона, который они ищут. –

Смежные вопросы