mysql база префиксов

я имел ввиду сам подход, например 1 - USA, 1868 - Тринидад. Так вот если Тринидада не будет в списке, то его код как бы начинается с 1 и всё равно звонок пройдёт.

отсортировать по длине кода.

Мерал, а точнее?

а точнее это основной запрос биллинга. соответвенно наиболее охраняемая тайна. бесплатно можно посмотреть в a2billing.org например.

мой вариант - написать процедурку где в отсортированной таблице, как советует meral, по длине кода взять кусок этой таблицы с id начиная с первой цифры искомого номера + длина макс возможного префикса, при этом отсортировать результирующую подтаблицу в обратном порядке. по этой подтаблице итерировать для поиска правильного кода. всего один SELECT и один LOOP - не считая опр. макс длины префикса :) в постгрезе еще проще - там есть рекурсивные запросы и массивы, то есть и процедурку делать не надо :) не забудьте про индексы...

угу. только вот не работает это нормально на 100к+ префиксам. потому и говорю что так не очевидно и все это патентуется.

как так не работает? а индексы на что? есть базка префиксов операторская - ровно 30к, откуда больше, просто интересно.. честно... :-) самый горбатый запрос - ~127мс, там без сортировок, с несколькими проходами по таблице, но возможно и скорее всего постгрес оптимизирует запросы внутри функции - не смотрел что выходит через EXPLAIN. не думаю что mysql сильно отличается по производительности... для оффлайн биллинга с миллионами звонков - согласен, да. но ведь я так понял человеку не это нужно...

SELECT * FROM directions WHERE name IN ('7','74','495','74951','749512','7495123','74951234','749512345','7495123456','74951234567') ORDER BY LENGTH(name) DESC LIMIT 1; Total runtime: 3.489 ms на 30-ке тыс записей (индекс btree). потом правда еще несколько раз придется просканировать таблицу чтобы подняться вверх по дереву к нужному типу префикса через цепочку parent...

супер хреновый хапрос. но вам виднее. 127 мс это очень много. 10 запросов в секунду(а скорее 4) и ваша база лежит. есть базы префиксов по 500к. сам видел. не забываем при тестах запроса про кеширование.

хотел свою функу запостить в ответ топикстартеру (где кажет 5 мс стабильно с индексами) - вот только движок сайта глючит- пишет что уже ответил... интересно было бы протестировать ее где 500к... любопытно стало узнать сколько будет попугаев...

самая большая таблица которую я видел у ОДНОГО провайдера была 1200к записей и весила под 3мб в csv. а таких провайдеров бывает под десяток. такчто индексы должны быть целочисленными и правильно построеннымы в биллинге который имеет дело больше чем с десятком звонков.

вот вам табличка, тестируйте http://pro-sip.net/temp/rate.csv . первая попавшееся, 4мб размерчик.