Поиск в MySQL

[LEXX2002]

Извините, если повторяюсь с темой, поиск по форуму не работает у вас, а сортировка по теме возвращает 0 строк.

Вопрос по поиску в MySQL.
Отсылаем запрос в БД
SELECT text FROM main WHERE text LIKE '%как%' OR text LIKE '%все%'
Возвращается всё поле text, которое довольно большое, что не удобно для пользователя, зачем ему вывод всего текста, ему нужно только * *слова %заданный запрос% слова. Т.е. как сделать, что бы перед и после искомой фразы стояло несколько слов, а всё остальное вырезалось.

[vadimiron]

Я думаю, лучше обрабатывать результат запроса с помощью средств языка (например PHP), а не с помощью средств базы данных.
PHP для этого предлагает мощный инструмент регулярных выражений, а также некоторые стандартные функции, возможности которых меньше, чем у регулярных выражений, но зато скорость их выполнения больше.

[mar]

vadimiron
вообще-то чем больше перекладывается на СУБД (по крайней мере в рамках реляционной модели данных) - тем лучше. Если что-то почему-то не удается - тогда оставляем за PHP.

LEXX2002
SUBSTRING,  SUBSTRING_INDEX и  иже с ними не спасут?
А REGEXP ;) ?

[vadimiron]

mar
Я наверно теорию плохо знаю :(
Для меня всегда было удобней пользоваться средствами PHP.
Вроде база данных должна хранить данные, а PHP их обрабатывать+закон, что нельзя верить никаким входящим данным.
Поэтому у меня сложилось вепчатление, что это должно быть как раз наоборот :)

[Prisoner]

detail.phpclub.net (http://detail.phpclub.net/article/mysql_search) . А какой у вас любимый ресурс? :)

[mar]

vadimiron
Для меня всегда было удобней
так мы все балансируем между собственным удобством и оптимальным кодом :) Это не призыв писать все на асемблере :)
Вроде база данных должна хранить данные
MySQL - не база, а СУБД (http://dev.mysql.com/doc/mysql/ru/What-is.html) (почувствуйте разницу :))
ну а про безопасные запросы Prisoner уже написал :) Могу только добавить, что для того, чтобы иметь возможность хоть минимально доверять тому что мы получаем из базы, класть их (данные) тоже нужно со всеми возможными предосторожностями

[LEXX2002]

Спасибо за SUBSTRING,  SUBSTRING_INDEX, прочитал про них, очень хорошая вещь, вот только где ими пользоваться? У меня скрипт $query = "SELECT text FROM main WHERE text LIKE '%". str_replace(" ", "%' OR text LIKE '%", $good). "%'";, а вот куда эту функция вставить  я не знаю :(. Если после $rezultat=mysql_query($query); будет уже переменные, которые уже не обрабатываются MYSQL. Вставлял как WHERE SUBSTRING (text……)….. не возвращает не одной строки.

[Vlad Drakula]

mar
про то что все по максимуму на перекладывать на базу я с тобой категорически не согласен, дело в том что как правило у хостеров стоит один сервер баз на несколько десятков веб серверов, так что его производительности может не хватать!

[mar]

Vlad Drakula
по-моему, по этому поводу (равно как и по поводу необходимости разделения серверов я уже не раз отвечала)
зы кстати, сервер приложений у хостеров тоже не для тебя одного заведен и, соответственно, апачей (man jail или welcome на *nix-форум =)) там тоже может крутиться много ;)
По поводу того, что для по-настоящему серьезных проектов нужно ставить свой сервер (пусть на colocation у провайдера), мы (в том числе с тобой) тоже вроде бы говорили :)
ззы а реляционную алгебру пока еще никто не отменял ;)

[Vlad Drakula]

я писал нечно подобное...
могу и объяснить как это написять полностью на MySQL.
это будет очень громоздко, т.к. MySQL не поддерживает рамены по регекспам!

так что это лучьше делать на ПХП

[archy]

хм... может стоит внимательней взглянуть на mnogosearch?

[mar]

Vlad Drakula
я не очень поняла слово "рамены" =(
По поводу regex в MySQL:
http://dev.mysql.com/doc/mysql/en/Regexp.html
Но человеку нужно, насколько я понимаю не это, а откусить кусок получающегося в результате запроса текста.
То есть можно написать что-то вроде:
SELECT SUBSTRING(str, FOR (LOCATE("substr",str)-15) FOR (CHAR_LENGTH("substr")+15)) FROM что_то_там WHERE str LIKE '%"substr"%' AND...
(Тут из поля str, выбранному по *условиям LIKE '%"substr"%' AND... *будет показана часть, начинающаяся за 15 знаков до искомого патерна и включающая его и еще 15 знаков. Желающие заморачиваться дальше могут попробовать отлавливать пробелы между словами, чтобы выводить не обрезки слов, а слова целиком

[Prisoner]

"Битва Титанов" :)
Правда битва есть суть оффтоп... кстати, я согласен с mar, мне тоже ближе философия выжимать из СУБД все до капли. Интересно, что тормознее при прочих равных условиях, MySql или PHP? ;)

[mar]

Prisoner Это не битва титанов, а сплошной офтоп :( Даже ответить человеку забыли за множеством важных дел :(
Но раз был задан еще один офтопный вопрос ;) - продолжим =)
Тормознутость PHP и MySQL сравнивать сложно - это разные системы и сделаны для разных вещей (это вроде, как, если кит на слона налезет, то кто кого поборет =)). Но:
во-первых, в PHP (не знаю, как в 5-ой версии, но подозреваю, что наследие осталось) не очень хорошо идет работа с массивами.
Во-вторых, это все-таки интерпритатор (со всеми вытекающими по скорости)... Установка его модулем апача и zend-optimazer помогают, но суть остается.
Про особенности работы СУБД с выборками я вроде уже как-то писала.
- Большинству из них легче один раз поднять "тяжелый" (с точки зрения человека) запрос, чем терпеть постоянные мелкие дерганья маленькими запросиками в цикле.
- Запросы обычно кешируются, отсюда дополнительный прирост в скоростях обработки.
- СУБД для того и сделаны, чтобы не изображать их из PHP и им подобных. Можно написать свою собственную СУБД, но во-первых это будет долго, а во-вторых писать надо на чем-нибудь приличном (как минимум на C, еще быстрее работать будет вещь, написанная будет на ассемблере)
- как показывает опыт лучше всего и быстрее всего в запросах отрабатывают вещи, напрямую идущие из понятий реляционной алшебры.
Резюме - поддерживаю идею выжимать из СУБД все до капли
Насчет провайдеров и серверов - повторяться не буду

[vadimiron]

Да, mar.
Такие вещи как кеширование запросов и др дают базам данных преимущество в данном споре, но мне кажется железо сегодня стало уже достаточно развитым и сильным, чтобы больше обращать внимание на нужды и привычки программиста.
Реальная разница между подходами, как мне кажется, будет просматриваться только на уровне очень больших проектов, а в основном для веб программирования это не свойственно (сложные большие проекты, насколько я заметил, всё равно пишут на других языках и используют их через cgi-интерфейс).
У меня в учебнике по с/с++ так и пишут, что развитие техники позваляет программисту использовать приёмы в программировании, обеспечивающие большею читабельность кода не обращая при этом на скорость его обработки. Я веду к тому, что мне удобней во многом использовать функции языка, чем инструменты базы.
Для меня следущий код является слишком нечитабельным и "некрасивым":

SELECT SUBSTRING(str, FOR (LOCATE("substr",str)-15) FOR (CHAR_LENGTH("substr")+15))
FROM что_то_там WHERE str LIKE '%"substr"%' AND...

а несколько подряд идущих функций кажется понятней.
Вообще, конечно, соблюдение законов теории и их правильное использование-это правильно. Это как раз то, что отличает *такого программиста-любителя, как я, от профессионала. Просто я думаю, сегодня это уже не так критично, как лет 15 назад и сегодня программист может уже отступать от теории, от того, как это правильно в сторону как это "красивей".


Исправлено: vadimiron, 21:10 8-10-2004

[mar]

vadimiron
Во-первых признаю, что пример показанный мною - действительно достаточно уродлив, сбацан на скорую руку и только для показа возможностей строковых функций.
Что касается осталного.
но мне кажется железо сегодня стало уже достаточно развитым и сильным, чтобы больше обращать внимание на нужды и привычки программиста
Да, только прогаммист с таким подходом никогда не сможет претендовать на роль системного программиста, ему вряд ли придется замахиваться на написание контроллеров и даже драйверов. Не у дел он окажется, скорее всего и в крупных проектах. А по твоим постам мне кажется, что у тебя есть все данные для профессионального подхода человека, знающего теорию и умеющего приложить ее на пракутике.
О web-программировании и больших проектах: они вполне свойственны друг другу =) Особенно с развитием в последнее время XML. Но даже, если его не трогать, то простой и вполне распространенный пример - ERP - технологии (они же АСУ) для территорриально разбросанных предприятий. В этом случае работает единая база данных и web-интерфейс, скажем через шифрованные каналы VPN (virtual private network) Вот и крупный проект с быстрорастущей базой данных, включающей склад, финансы и т.д. Другой пример - интернет-магазин, связанный со складом. Или крупный форум (не даром этот - увы! часто глючит =() И т.д. и т.п. Поскольку мне приходилось (и пока еще, к счастью приходится =)) принимать участие в разработках проектов подобного уровня, могу сказать, что на своих тестовых рабочих площадках *(на девелоперских машинах при очень неплохой технике), нам приходилось отказываться от всего лишнего в нагрузках на PC, чтобы они могли тянуть *проекты с реальными базами, слитыми с площадок заказчиков. (Правда в нашей фирме большинство - юниксоиды, то есть люди с навыками сисадминов, поэтому такие вещи были возможны. Так что надеяться на бесконечные возможности современной техники не стоит - они тоже не безграничны =(
Что касается того, что было лет 15 назад, то мне почему-то кажется, что тогда были свои заморочки со своими отступлениями от теории =). (я с самого начала сказала, что не предлагаю писать на асемблере ;))
Не берусь оценивать сказанное в учебнике по C++, скорей всего имелось в виду не наплевательство на скорость обработки кода, а сам подход к ООП (то есть классы со всеми их прибамбасами, облегчающие написание программ, хотя и скрывающие в себе прямой подход к проблеме ). Хотя что-то мне не припомнится подобных оговорок у Страбстраупа ;) В общем, с чего и начала - мы все балансируем между...
Кстати по поводу красивого кода отступлений и неотступлений: приведу пример работы *в среднем, или достаточно крупном проекте при работе с базами данных из ПХП:
- набор классов ПХП (например на основе наследования от той же PHPlib), выстраивающихся по вертивали:
- первый слой - структура базы (включая, если это не MYSQL, а хотя бы PostgreSQL VIEW и хранимые процедуры
- следующий слой базовых классов (мы используем PHPLib)
- дальше - что-то вроде мененджеров работы с базами данных
- файлы обработки запросов форм и обработки результатов запросов при помощи вызова функций этих классов - мененджеров БД
- шаблон вывода (пусть дизайнеры резвятся отдельно от программистов =)
При такой структуре над одним проектом реально может работать группа из нескольких человек, причем одновременно. (При выполнении определенных соглашений по правилам написания кода, конечно). При этом сам файл обработки форм и результатов будет достаточнео коротким и читабельным. (Хотя, конечно, в скорости при такой многоступенчатой структуре несколько проигрываем. С другой стороны сильно выигрываем за счет слоя БД и максимального использования запросов =) )
И еще - MySQL все-таки не самый мощный из бесплатных СУБД. Учтите это ;)