|
Извините, если повторяюсь с темой, поиск по форуму не работает у вас, а сортировка по теме возвращает 0 строк.
Вопрос по поиску в MySQL. Отсылаем запрос в БД SELECT text FROM main WHERE text LIKE '%как%' OR text LIKE '%все%' Возвращается всё поле text, которое довольно большое, что не удобно для пользователя, зачем ему вывод всего текста, ему нужно только * *слова %заданный запрос% слова. Т.е. как сделать, что бы перед и после искомой фразы стояло несколько слов, а всё остальное вырезалось. |
Я думаю, лучше обрабатывать результат запроса с помощью средств языка (например PHP), а не с помощью средств базы данных.
PHP для этого предлагает мощный инструмент регулярных выражений, а также некоторые стандартные функции, возможности которых меньше, чем у регулярных выражений, но зато скорость их выполнения больше. |
vadimiron
вообще-то чем больше перекладывается на СУБД (по крайней мере в рамках реляционной модели данных) - тем лучше. Если что-то почему-то не удается - тогда оставляем за PHP. LEXX2002 SUBSTRING, SUBSTRING_INDEX и иже с ними не спасут? А REGEXP ;) ? |
mar
Я наверно теорию плохо знаю :( Для меня всегда было удобней пользоваться средствами PHP. Вроде база данных должна хранить данные, а PHP их обрабатывать+закон, что нельзя верить никаким входящим данным. Поэтому у меня сложилось вепчатление, что это должно быть как раз наоборот :) |
detail.phpclub.net . А какой у вас любимый ресурс? :)
|
vadimiron
Цитата:
Цитата:
ну а про безопасные запросы Prisoner уже написал :) Могу только добавить, что для того, чтобы иметь возможность хоть минимально доверять тому что мы получаем из базы, класть их (данные) тоже нужно со всеми возможными предосторожностями |
Спасибо за 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……)….. не возвращает не одной строки.
|
mar
про то что все по максимуму на перекладывать на базу я с тобой категорически не согласен, дело в том что как правило у хостеров стоит один сервер баз на несколько десятков веб серверов, так что его производительности может не хватать! |
Vlad Drakula
по-моему, по этому поводу (равно как и по поводу необходимости разделения серверов я уже не раз отвечала) зы кстати, сервер приложений у хостеров тоже не для тебя одного заведен и, соответственно, апачей (man jail или welcome на *nix-форум =)) там тоже может крутиться много ;) По поводу того, что для по-настоящему серьезных проектов нужно ставить свой сервер (пусть на colocation у провайдера), мы (в том числе с тобой) тоже вроде бы говорили :) ззы а реляционную алгебру пока еще никто не отменял ;) |
я писал нечно подобное...
могу и объяснить как это написять полностью на MySQL. это будет очень громоздко, т.к. MySQL не поддерживает рамены по регекспам! так что это лучьше делать на ПХП |
хм... может стоит внимательней взглянуть на mnogosearch?
|
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 знаков. Желающие заморачиваться дальше могут попробовать отлавливать пробелы между словами, чтобы выводить не обрезки слов, а слова целиком |
"Битва Титанов" :)
Правда битва есть суть оффтоп... кстати, я согласен с mar, мне тоже ближе философия выжимать из СУБД все до капли. Интересно, что тормознее при прочих равных условиях, MySql или PHP? ;) |
Prisoner Это не битва титанов, а сплошной офтоп :( Даже ответить человеку забыли за множеством важных дел :(
Но раз был задан еще один офтопный вопрос ;) - продолжим =) Тормознутость PHP и MySQL сравнивать сложно - это разные системы и сделаны для разных вещей (это вроде, как, если кит на слона налезет, то кто кого поборет =)). Но: во-первых, в PHP (не знаю, как в 5-ой версии, но подозреваю, что наследие осталось) не очень хорошо идет работа с массивами. Во-вторых, это все-таки интерпритатор (со всеми вытекающими по скорости)... Установка его модулем апача и zend-optimazer помогают, но суть остается. Про особенности работы СУБД с выборками я вроде уже как-то писала. - Большинству из них легче один раз поднять "тяжелый" (с точки зрения человека) запрос, чем терпеть постоянные мелкие дерганья маленькими запросиками в цикле. - Запросы обычно кешируются, отсюда дополнительный прирост в скоростях обработки. - СУБД для того и сделаны, чтобы не изображать их из PHP и им подобных. Можно написать свою собственную СУБД, но во-первых это будет долго, а во-вторых писать надо на чем-нибудь приличном (как минимум на C, еще быстрее работать будет вещь, написанная будет на ассемблере) - как показывает опыт лучше всего и быстрее всего в запросах отрабатывают вещи, напрямую идущие из понятий реляционной алшебры. Резюме - поддерживаю идею Цитата:
|
Да, mar. Такие вещи как кеширование запросов и др дают базам данных преимущество в данном споре, но мне кажется железо сегодня стало уже достаточно развитым и сильным, чтобы больше обращать внимание на нужды и привычки программиста. Реальная разница между подходами, как мне кажется, будет просматриваться только на уровне очень больших проектов, а в основном для веб программирования это не свойственно (сложные большие проекты, насколько я заметил, всё равно пишут на других языках и используют их через cgi-интерфейс). У меня в учебнике по с/с++ так и пишут, что развитие техники позваляет программисту использовать приёмы в программировании, обеспечивающие большею читабельность кода не обращая при этом на скорость его обработки. Я веду к тому, что мне удобней во многом использовать функции языка, чем инструменты базы. Для меня следущий код является слишком нечитабельным и "некрасивым": Код:
SELECT SUBSTRING(str, FOR (LOCATE("substr",str)-15) FOR (CHAR_LENGTH("substr")+15)) Вообще, конечно, соблюдение законов теории и их правильное использование-это правильно. Это как раз то, что отличает *такого программиста-любителя, как я, от профессионала. Просто я думаю, сегодня это уже не так критично, как лет 15 назад и сегодня программист может уже отступать от теории, от того, как это правильно в сторону как это "красивей". [s]Исправлено: vadimiron, 21:10 8-10-2004[/s] |
vadimiron
Во-первых признаю, что пример показанный мною - действительно достаточно уродлив, сбацан на скорую руку и только для показа возможностей строковых функций. Что касается осталного. Цитата:
О web-программировании и больших проектах: они вполне свойственны друг другу =) Особенно с развитием в последнее время XML. Но даже, если его не трогать, то простой и вполне распространенный пример - ERP - технологии (они же АСУ) для территорриально разбросанных предприятий. В этом случае работает единая база данных и web-интерфейс, скажем через шифрованные каналы VPN (virtual private network) Вот и крупный проект с быстрорастущей базой данных, включающей склад, финансы и т.д. Другой пример - интернет-магазин, связанный со складом. Или крупный форум (не даром этот - увы! часто глючит =() И т.д. и т.п. Поскольку мне приходилось (и пока еще, к счастью приходится =)) принимать участие в разработках проектов подобного уровня, могу сказать, что на своих тестовых рабочих площадках *(на девелоперских машинах при очень неплохой технике), нам приходилось отказываться от всего лишнего в нагрузках на PC, чтобы они могли тянуть *проекты с реальными базами, слитыми с площадок заказчиков. (Правда в нашей фирме большинство - юниксоиды, то есть люди с навыками сисадминов, поэтому такие вещи были возможны. Так что надеяться на бесконечные возможности современной техники не стоит - они тоже не безграничны =( Что касается того, что было лет 15 назад, то мне почему-то кажется, что тогда были свои заморочки со своими отступлениями от теории =). (я с самого начала сказала, что не предлагаю писать на асемблере ;)) Не берусь оценивать сказанное в учебнике по C++, скорей всего имелось в виду не наплевательство на скорость обработки кода, а сам подход к ООП (то есть классы со всеми их прибамбасами, облегчающие написание программ, хотя и скрывающие в себе прямой подход к проблеме ). Хотя что-то мне не припомнится подобных оговорок у Страбстраупа ;) В общем, с чего и начала - мы все балансируем между... Кстати по поводу красивого кода отступлений и неотступлений: приведу пример работы *в среднем, или достаточно крупном проекте при работе с базами данных из ПХП: - набор классов ПХП (например на основе наследования от той же PHPlib), выстраивающихся по вертивали: - первый слой - структура базы (включая, если это не MYSQL, а хотя бы PostgreSQL VIEW и хранимые процедуры - следующий слой базовых классов (мы используем PHPLib) - дальше - что-то вроде мененджеров работы с базами данных - файлы обработки запросов форм и обработки результатов запросов при помощи вызова функций этих классов - мененджеров БД - шаблон вывода (пусть дизайнеры резвятся отдельно от программистов =) При такой структуре над одним проектом реально может работать группа из нескольких человек, причем одновременно. (При выполнении определенных соглашений по правилам написания кода, конечно). При этом сам файл обработки форм и результатов будет достаточнео коротким и читабельным. (Хотя, конечно, в скорости при такой многоступенчатой структуре несколько проигрываем. С другой стороны сильно выигрываем за счет слоя БД и максимального использования запросов =) ) И еще - MySQL все-таки не самый мощный из бесплатных СУБД. Учтите это ;) |
| Время: 11:55. |
Время: 11:55.
© OSzone.net 2001-