Korcarв общем 4 запроса сделал. надеюсь годно получилось??????

maytonДавайте сверх-задачу. Мы не знаем сведений о СУБД.это будет сразу не оптимально.

mayton1) Like создает нагрузку класса full-table scan.ну фулскан для like не имеет смысла, потому как поиск по like подразумевает не полную информацию о искомом, как правило отдельные части содержимого и порядок вхождения этих частей не известен
поэтому сканировать полностью таблицу нет смысла - вернёт много чего лишнего
следовательно надо ограничиться в приемлемое число возвращаемых записей - супермаксимум 20, реально 5 достаточно
если в найденном нет искомого - добавляем дополнительный like .
запускаем поиск - как правило находим уже с помощью глаз :)
практически - в 28000записях - достаточно 2 like
в 3лямах 3-4
нагрузка на субд практически нулевая- если у вас база в 3ляма записей для оперативной работы, значит и железо будете для этого использовать нормальное, и память не пожалеете. в моём примере 2.9лямов - 660мег на диске, выделяем 5гиг памяти - и поиск like происходит в памяти, без обращения к диску.
по скорости - при 28000 записях - на слабом железе и малой памяти - отображение при вводе каждого символа происходит практически мгновенно .
при 2.9млн - 3like -1.6 сек/ 1like-0.3сек(хорошее железо)нагрузка на проц на заметна по диспетчеру задач...

Korcarу меня запроса всего 4, а вопросов у тебя аж 6! чего спрашиваешь то? тебе наверное надо умерить аппетиты)у меня 1 запрос
как ты насчитал 6?

maytonТак что. Откажешся кодить?сделаю оптимально.

maytonПочему 20? Почему 5? Если клиент захочет все?потому что такой поиск оптимален когда вывод происходит по мере ввода
если данныз не много ~30000, можно начинать поиск с 1 введённого(теоретически - глупо, но проще код, меньше проверок) и соответственно при 1 введённом символе выведет почти всё
при 2 символах чуть меньше.
соответственно первоначально есть смысл ограничить набор найденного,
при наборе 2групп символов (если чел знает что ищет) набор найденного уже 5-10 позиций это при исходных данных в 30000.
это из практических наблюдений.


тут ты получишь ахинею


так ты получишь искомое
maytonНикаких глаз. Глаза врут. К чорту глаза.
в 5-10 строчках глаз не соврёт - проверено практикой

[quote mayton]Вообще не понял эту бухгалтерию. Почему 2? Почеу 3 ляма?

[quote ]оговорка по Фрейду
реально проверено на таблице в 2 950 000 , поэтому и 2-3 ляма
maytonПри чем здесь это? Что это за метрики? Давайте пока не будем это учитывать. Бесполезная инфа
и к моему предлагаемому интерфейсу не несет никакой пользы.это инфа к сведению
что б было что сравнивать по скорости

chpashaпо-моему кто-то кого-то не так понял. когда ты пишешь запрос вида like - бд может быть вынуждена просканировать все записи - это называется full scan если ты ввёл 2 символа и вываливаешь всё что нашёл этот like- этот объём никому не нужен.
поэтому и не смысла делать фулскан, есть смысл остановить его при нахождении 5-10 записей и добавить что выбрано очень много -добавьте критерии для фильтра.

maytonСделай. Интерфейс видел? Кодь.у меня сделано для веб без всяких интерфейсов :)

maytonТы понимаешь что такое поиск like a Google?
а ты что хочешь найти?

maytonПокеж.дай набор данных сделаю демку.

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

забыл никЭто как? Слезно попросить ДБ?не помню как в mssql, но в mysql есть Limit n

maytonТы понимаешь что такое поиск like a Google?для того чтоб найти что-то в одном поле надо так


что б в нескольких полях

maytonТвой второй запрос не будет работать.твой найдёт кучу лишнего
ищут то где есть и первый параметр и второй и третий
И , а не ИЛИ