Как реализован поиск вариантов городов

это называется suggest, иногда еще autocomplete.

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

Строка "моск" и тематика клуба наводит на мысли о поиске городов, их в россии считанные тысячи, в собранном виде трехбуквенных сочетаний ключей будет не много, особенно если отсеч поселки городского типа и небольшие города из 5-10 тысяч человек - останется порядка трех-четырех тысяч названий, из них сделать ключики - пара килобайт, и с помощью них делать предварительную фильтрацию запросов, а дальше аякс запрос на сервер, если ключик найден, за адекватными результатами имеющихся названий. ы. Я бы сделал кешируемый json объект из трех-четырех букв, где первую букву - в ключи корневому объекту, внутри каждой буквы по ключу второй буквы, и там внутри хэш из ключен третих букв. Если нужны только сравнительно большие города (скажем, от 50к жителей) - то все данные в json займут примерно 1000*10*(2+6) - где-то 80 кб текста, а в gz и того меньше. А если экпортировать ключи в js (не json с юникод кодированием аля "\u4012"), то максимум это займет, если экспортировать так ["abc","def",...], а затем собрать на клиенте в хэш, 6символов*(32^3), ~195 Кб, но в реальности раз в 10 меньше, потому что нет городов ыыы и ььь. А можно вообще строкой, разделенной запятыми передать. "мос|оск|скв|ква".split("|"), зачем лишние байты ;-) В общем, это дело десятое, как ты будешь данные выгребать оттуда. ;-))

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

p.s. Кстати, это предварительная очень грубая фильтрация, и хватит двух символов... 200 байт на ключики + 200 байт на фукцию фильтра. 3 избыточно.

Спасибо)