выборка из таблици
Пример данные должны виводится и при значении "мой запрос" и при "запрос мой".
В phpmyadmin есть такая функция но запрогить это дело не выходит.
Задача: надо сделать выборку из таблици с условием что некоторое текстовое поле эквивалентно заданой строке без учета порядка размещения слов. То есть если в ячейке есть все слова из заданой фразы(без учета их порядка) тогда выводить данные.
Пример данные должны виводится и при значении "мой запрос" и при "запрос мой".
В phpmyadmin есть такая функция но запрогить это дело не выходит.
Я бы сделал такое с помощью user function. опять же не указана субд, но судя по тому что ты, видимо, пишешь на пхп, рискну предположить что субд mysql. Насколько я помню там поддерживаются функции.
Соответсвенно пишешь функцию, параметры - две строки, возвращает нул если твое условие не проходит и не нул если все ок. В самой функции парсишь эти две строки,части строк записываешь в таблицу и проверяешь условие. имхо, так...
Либо еще как вариант, формировать запрос динамическии на клиенте (если строку можно передать как параметр, т.е. если запрос выполняется для какой-то одной конкретной строки, а не так - например , есть две таблицы с текстовыми полями, требуется вывести все записи второй таблицы которые удовлетворяют упомянутым выше условиям для всех строк первой таблицы - тогда параметрический запрос конечно не прокатит)
Я бы сделал такое с помощью user function. опять же не указана субд, но судя по тому что ты, видимо, пишешь на пхп, рискну предположить что субд mysql. Насколько я помню там поддерживаются функции.
Соответсвенно пишешь функцию, параметры - две строки, возвращает нул если твое условие не проходит и не нул если все ок. В самой функции парсишь эти две строки,части строк записываешь в таблицу и проверяешь условие. имхо, так...
Пример данные должны виводится и при значении "мой запрос" и при "запрос мой".
Только это ужасно неоптимально и стандартными средствами оптимизации подвергнуто быть не может - оператор like по определению не использует индекс.
Я сейчас скажу глупость, но для полнотекстового поиска в БД есть Oracle Text. Думаю, догадываетесь, в какой СУБД.
Только это ужасно неоптимально и стандартными средствами оптимизации подвергнуто быть не может - оператор like по определению не использует индекс.
Я сейчас скажу глупость, но для полнотекстового поиска в БД есть Oracle Text. Думаю, догадываетесь, в какой СУБД.
Думаю проблема была поставлена не как формирование запроса для фразы "мой запрос", а как выбор общего подхода для решения...
И не очень понятно, зачем городить полнотекстовые каталоги поиска для такой задачи...так же не очень понятно при чем здесь Оракл если бд MySQL.
Думаю проблема была поставлена не как формирование запроса для фразы "мой запрос", а как выбор общего подхода для решения...
Во-первых, вопрос задавал не ты. Во-вторых, чем не стратегия:
- разобрать строку на слова по некоторому набору разделителей
- построить динамический запрос с like по каждому слову.
В третьих, предложенное тобой решение в виде написания собственной функции ничем не лучше моего - в обоих случаях выполняется полный просмотр таблицы.
Мы не знаем, какова задача, у обоих - только предположения. А Oracle - для примера. Чтобы видели, куда расти.
Во-первых, вопрос задавал не ты. Во-вторых, чем не стратегия:
- разобрать строку на слова по некоторому набору разделителей
- построить динамический запрос с like по каждому слову.
В третьих, предложенное тобой решение в виде написания собственной функции ничем не лучше моего - в обоих случаях выполняется полный просмотр таблицы.
Мы не знаем, какова задача, у обоих - только предположения. А Oracle - для примера. Чтобы видели, куда расти.
Во-первых - согласен, не я =), может ты понял вопрос как-то иначе чем я, у каждого есть своя точка зранеия.
Во-вторых не нужно дублировать, про динамический запрос было упомянуто, ты просто написал конкретную реализацию, вот почему я про это упомянул.
В-третьих. Что отработает быстрее проверка по всей таблице оператором like столько раз сколько частей в строке или парсинг двух строк? Надо конечно смотреть на конкретном примере, но мне почему-то кажется что второе.
В-четвертых, всем спасибо, не будем отвлекаться от топика, думаю автор темы сам выберет подходящее решение.
Мы не знаем, какова задача, у обоих - только предположения.
Если конкретизировать задачу то:
Имеется БД под мускулом, в ней таблица с товарами(наименование, номер в таблице), есть файл с нужными наименованиями с этого файла читается наименование и потом по этому наименованию нужно достать номер из таблицы.
Загвоздка в том что одни и те же товары мы закупаем у нескольких поставщиков(у каждого свои коды товаров поэтому единой системы кодификации нет и приходится работоть с текстовым полем наименование) , а наименования одних и тех же товаров в их прайсах часто отличается порядком размещения слов(типа "Стул деревянный" и "Деревянный стул") по этому нужен поиск, который бы проверял наличие всех слов из заданной строки в поле "наименование"...
В-третьих. Что отработает быстрее проверка по всей таблице оператором like столько раз сколько частей в строке или парсинг двух строк?
А откуда такая уверенность? Есть планы запросов в доказательство? Если MySQL действительно делает отдельный просмотр на каждый like в запросе - тут уж извините. Свобода свободой, но головой думать разработчикам тоже надо.
А откуда такая уверенность? Есть планы запросов в доказательство? Если MySQL действительно делает отдельный просмотр на каждый like в запросе - тут уж извините. Свобода свободой, но головой думать разработчикам тоже надо.
Читаем посты внимательнее. Я написал что "надо смотреть на конкретном примере, но мне кажется что функция быстрее". Свое мнение я основываю на опыте. Может конкретно в MySQL это не так, поэтому здесь я точно не утверждаю, если читать внимательно - это понятно. Чтобы сказать точно нужно, еще раз повторюсь, смотреть на конкретном примере, а копаться в профайлере, к тому же ради того чтобы кому-то что-то "доказывать"... =)
К тому же это может сделать и сам автор темы, у него более весомые причины чем "доказательства", потом поделиться результатами, если я не прав с удовольствием это признаю и запомню - опыт лишним не бывает!
По теме: Если есть много строк для которых нужно искать записи в БД (судя по написанному выше посту так и есть) то все-таки рекомендую вынести все либо на сервер, либо на клиент (если таблица не очень большая), а не формировать для каждой строки динамический запрос. Здесь уже речь идет не об эффективности SQL операторов, а о том сколько тратится времени для выполнения сервером запроса с клиента по каждой строке. И вот здесь я уверен точно, что это будет дольше чем если сделать один запрос а все остальное возложить на сервер, или наоборот, получить данные с сервера и обрабатывать их скопом на клиенте. Т.е. не обращаться на каждой итерации к серверу. Хотя если к быстродействию нет особых требований, то просто делай - как удобнее =) Потому что часто много времени тратится на оптимизацию, которая совсем не нужна и в итоге снижается экономическая выгода от кода.
Чтобы сказать точно нужно, еще раз повторюсь, смотреть на конкретном примере, а копаться в профайлере, к тому же ради того чтобы кому-то что-то "доказывать"... =)
Я к тому, что это первая оптимизация, приходящая в голову. Считая разработчиков нормальными людьми, а не дегенератами, принимаю по умолчанию, что эта мысль им также пришла в голову. Простая человеческая логика. Разрабатывая сервер БД, разве ты бы сделал не так?