xploИнтересно узнать: сможет ли мускль справиться с такой задачей лучше MSSQL сервера?
Подозреваю, это зависит в первую очередь от около 250 запросов различной сложности

lockylimit даже лучше - при динамической формировании запроса нет нужды знать
- есть клауза where или нет. rownum в этом плане хуже.
Опуская соображения о подходе - при формировании запроса с rownum также нет необходимости думать о существовании where.

Что, боюсь, limit вряд ли сможет выполнить, так это пронумеровать строки в выборке. Знаете, такой довольно типичный пункт всяких печатных форм - "номер по порядку".

lockyа как тоже самое сделать с rownum? Не задрочки ради, действительно
интересно.

lockyТоже вариант, хотя и хреновый, если честно :(
т.е. если в том же MySQL можно сделать (условно)
и регулировать поведение путем изменения limitlist, то в твоем варианте
- надо модифицировать весь запрос...
Довольно странное рассуждение. Попробую по пунктам.

Во-первых, что за "модифицировать весь запрос", какими критериями это выражается? В том и в другом случае у нас есть некий "исходный запрос" и есть формальный способ получить из него "запрос с ограничениями". Что нас интересует - насколько такой формальный способ надежен во-первых и качественен во-вторых (здесь под качеством понимается производительность и прочие параметры [не]ухудшения).

Далее, я бы предостерег от пусть даже условной, но тем не менее попытки думать в терминах select+from+where. Эта модель обламывается на нетривиальных примерах и служит вечным источником проблем вида "наш крутейший суперпупердвижок не может работать с тем запросом, который нужен". Скажем, я помню один неплохой на первый взгляд dbgrid, который рушился при попытке подсунуть ему запрос с union; все такие запросы приходилось оборачивать во view. Вопрос в принципе философский, но имхо - если автор фреймворка говорит "ну здесь у нас сложных запросов не будет", его надо немедленно выгонять по служебному несоответствию (почему фреймворка - потому что задача "универсально подсунуть" встает именно в подобных случаях).

Реально - надо понимать, что исходным может быть абсолютно любой запрос, и наша задача - придумать способ, который будет работать всегда или почти всегда. Попытка парсить запрос, разобрать его на части чаще всего убивает это требование (а в оставшихся - требует очень нехилой трудоемкости). Обертывание в подзапрос - этому требованию чаще всего соответствует; даже если я употреблю в запросе with, group by, order by, minus и model в одном флаконе - внешний rownum таки сработает.

Про MSSQL в данном случае ничего сказать не могу.

lockyВообще-то, результаты получаются разные...
Как Вам сказать...... вообще-то в документации по использованию rownum специально и подробно разжевана та ошибка применения rownum, которую Вы сейчас демонстрируете. На пальцах: в том синтаксисе, который Вы использовали в первом случае, движок делает именно то, что Вы ему сказали. То есть: выбирает первые десять строк и сортирует их по object_name.

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

lockyдля MySQL - всё не так плохо.

Честно говоря, я не понимаю, зачем Вы уделяете столько внимания заведомо некорректным конструкциям.

lockyТем более - можно просто к исходному запросу добавить limit - и получим
то, что надо.
Это какая-то религиозная разница. Объясните мне, какая разница между


и


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

lockyт.е. вместо "дописывания" запроса (как в MySQL) или "оборачивания" (как
в Оракле, правда толку с этого?) необходимо менять select list.
К совету забыть про "select list" Вы, видимо, так и не прислушаетесь....

locky >Это какая-то религиозная разница.
Нет. Это - вполне себе принятая практика в написании систем.
Брр... не понял ответа. Вы уверены, что это ответ именно на эти слова?

locky> К совету забыть про "select list" Вы, видимо, так и не прислушаетесь....
Потому что у нас с Вами - задачи несколько разные.
У Вас - "с нуля написать систему", у меня - заставить (с минимальными
переделками) бежать уже сущствуеющую систему,
Вы неудачно ставите акценты. Та задача, которую стараюсь решать я - "дать системе бежать вместо ползанья". И постепенно до моих начальников доходило, что если я упорно талдычу о том, что "здесь лучше сделать так", то дешевле сразу послушаться.

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

lockyНе всегда такой подход возможен - увы. Иногда приходится идти на компромиссы.
Хм. По моему опыту, такой подход возможен практически всегда, и вполне сочетается с необходимостью достижения тех или иных промежуточных целей - если, конечно, обе стороны готовы проявить должную гибкость и желание пораскинуть мозгами. Другой вопрос, что чаще всего он оказывается связан с геморроем уровня "а нафига оно мне надо?"