[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 назад и сегодня программист может уже отступать от теории, от того, как это правильно в сторону как это "красивей".


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

[mar]

vadimiron
Во-первых признаю, что пример показанный мною - действительно достаточно уродлив, сбацан на скорую руку и только для показа возможностей строковых функций.
Что касается осталного.

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

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