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Конечно, на фоне остальных тормозов эти долюшечки процента заметить будет сложно. Главное что потеря все же будет и она будет не нулевой...
Это скорее долюшечки долюшечек процента. Их будет очень трудно заметить даже на фоне "эффективности строковых операций".

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

White OwlВовсе нет.
Вовсе да.

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

White OwlЛюдей которые скачут между несколькими БД с разными настройками - по пальцам пересчитать.
Угу. Всего лишь "все сотрудники софтовых контор и консалтеров".

White OwlИ в конце-концов, я с трудом представляю себе прикладную задачу в которой надо делать регистрозависимое сравнение.
Хотя бы контроль изменения поля. Допустим, система поддерживает историю смены фамилий, а для скорости денормализована - в запись человека внесена текущая фамилия. Обнаружили мы с Вами, что надо поправить фамилию ИВанов на Иванов. Поправили - а триггер обнаружил, что фамилия ни фига не изменилась, и менять денормализованное поле не стал...

White OwlВообще-то, клиент вполне может прочитать все настройки сервера/базы/сессии и соответственно настроится самому.
Угу, может настроиться. Добавить upper в нужные sql-и....... Офигенно разумный режим.

tchingiz
Необычная работа привычных вещей - немного другая вещь, хотя и связанная. Честно говоря, по Вашему примеру я сходу предположил, что он сумел как в Фортране - присвоить константе "а" значение "ab"