Мне главное ход мыслей для выборки было понять - притупил:)
Запросы повертеть уже смогу)
Потестирую на реальных данных - там будет видно по скорости...но это уже отдельная тема)
По второму немного не так опять же)
Но первый можно объединить с другим запросом в эту же таблицу, но хочется более быстрый вариант в плане скорости...
MrTNTminer, На крайняк "перелей" в новую таблицу с trim в PHP...костылёк...но если это всего лишь раз сделать и дальше пользоваться новой таблицей + новые поступающие данные обрабатывать на входе по одному принципу, то, чем не вариант...чем несколько часов биться с такой проблемой...=)
И как выше писали...возможно одинаковые русские буквы с английскими перепутаны в данных...их тоже можно "пофиксить" заодно, если использовать костыль выше...
Допустим так:
При масштабе 10 (условно) - группируй рядом лежащие точки в радиусе X (условно), как одну точку...и показывай вместо названия этой точки просто кол-во точек в ней...
При более близком масштабе начинай уменьшать радиус группировки X...
karpo518, Из вашего вопроса я думал, что LIKE не подходит... Не потому что с его помощью сделать нельзя, а потому что медленно (в таком варианте он не использует индексы) + зачем то Вы припрели MATCH, что ещё раз меня убедило про ненужность LIKE...А то, что "AND" Вам сделал погоду... Тут я улыбнулся :) Я и в своём примере "AND" не указал, т.к. это было само собой разумеющееся... Извиняйте :)
P.S.: LOCATE тоже индексы не любит...
P.S.S.: Добавил в пример "AND"... :)
Хранение деревьев в Mysql какие есть способы?