i'm_noviceтак вот интересно, чьи функции "быстродейственнее" в итоге работы скрипта/программы: языка программирования или субд?
Затрудняюсь придумать задачу, в которой ответ на этот вопрос имеет хоть сколько-нибудь практическое значение. Здесь стоит думать об архитектурно верном решении, а не о быстродействии.

White OwlВерность решения с точки зрения архитектуры зависит так же и от быстродействия.
Не "от быстродействия", а "от быстродействия, имеющего значение с точки зрения решения итоговой задачи". Для задач вида "скриптовый язык работает с БД" думать о быстродействии строковых операций, мягко говоря, смешно.

А вот программистов, которые сделав "тест на быстродействие" запихнут эти операции туда, где им решительно не место с архитектурной точки зрения, я к сожалению очень даже себе представляю.

White OwlОдно маленькое "но", ты забыл сказать как надо определить где этим самым операциям место?
Думать головой.

White OwlДай свою инструкцию по определению правильного места для строковых операций.
Так же, как и для любых других операций. Надеюсь, ты не просишь краткой инструкции по конструированию программных систем?

Скажем, если мы считаем, что фамилия должна быть в initcaps-е - это надо делать на сервере (можно, но необязательно, продублировать на клиенте). Скажем, если мы считаем, что суммы должны выводиться как 9'990.00 - этого не надо делать на сервере. Однако, более-менее кратко пересказать методику определения "где когда" - увы, не способен.

Kachalov- не смешно. Удачно созданная программа на скриптовом языке может работать на порядок быстрее неудачно созданной, а учитывая возможность интенсивного использования такой программы
Следует выкинуть "скриптовой язык" и писать на инструментах, нормально тянущих серьезную нагрузку.

Kachalov- и уничтожить всех программистов использующих для web-программирования PHP :)
Зачем тратить силы на лишние непродуктивные действия? Если все сайты в мире станут "серьезными" - сами вымрут, а если не станут - пусть лучше живут, иначе пользователи, глядишь, кого другого дергать начнут.

Kachalov- кривой код можно написать на любом языке :)
Безусловно. Однако, снявши голову - по волосам не плачут, а выбрав такую конфигурацию - почему-то начинают бороться за такты.

White OwlВообще-то, существуют базы данных умеющие сравнивать текстовые значения без учета регистра.
К использованному в примере substr эта логика тоже относится? :)

White OwlИ на таких БД использование функции upper() для сравенения приводит к бессмысленной трате процессорных ресурсов.
Не уверен, кстати. Зависит от реализации.

White Owlпочему не уверен?
Потому что зависит от реализации.

White OwlЕсли бд работает в режиме нечувствительности к регистрам,
В скобках отметим, что за такие режимы надо отрывать руки.

White Owlто любая операция сравнения строк будет неявно вызывать внутренний аналог upper/lower или функцию сравнения с учетом страниц для юникодных строк. Оборачивать это своим собственным вызовом upper() приведет к двойной работе или хотя бы проверке, надо эту работу проводить второй раз или не надо.
Угу. Игнорирование вызова upper на стадии построения плана - потребуется поставить очень нетривиальный эксперимент, чтобы обнаружить следовые количества влияния на производительность.

White OwlВот теперь можешь ехидничать :)
Спасибо, только этого и ждал :)

White OwlНо вообще-то, автор топика говорил не про строковые функции в where, он говорил про строковые функции в определении вычислимых колонок в запросе. Это все-таки совершенно другое...
Мне тоже пришла в голову именно такая трактовка, но вообще-то мод прав, найдутся и персонажи, который под лозунгом "и вообще еще неизвестно, как эта субд считает регэкспы" сделают фильтрацию на клиенте.

White Owl softwarer White OwlЕсли бд работает в режиме нечувствительности к регистрам,
В скобках отметим, что за такие режимы надо отрывать руки.Почему???
Потому что код, корректность которого зависит от режима работы базы - кошмар с точки зрения эксплуатации и сопровождения. База может понимать операцию сравнения так, может понимать иначе, может иметь разные по синтаксису операции "чувствительного" и "нечувствительного" сравнения - ничуть не возражаю, но за наличие настройки уровня базы "как следует сравнивать строки" надо бить, и больно. Вон, ораклоиды додумались не так давно сделать чувствительную сортировку - и с тех пор не утихают вопросы "а какого хрена здесь сортируется не так, как вон там?"

В немного меньшей степени это верно для возможности сделать настройку в приложении. То есть "ALTER SESSION SET... " - это несколько лучше, чем параметр базы, приложение по крайней мере может настроить свой контекст - но все равно оказывается, что работа программных модулей уродуется внешними по отношению к ним настройками; достаточно представить себе общий модуль, используемый в нескольких проектах, в одном из которых вдруг решили "поменять настройку".

White OwlКонечно, на фоне остальных тормозов эти долюшечки процента заметить будет сложно. Главное что потеря все же будет и она будет не нулевой...
Это скорее долюшечки долюшечек процента. Их будет очень трудно заметить даже на фоне "эффективности строковых операций".

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