LelikBolekДовольно часто встречал сообщения что разработчики все изменения таблиц делают через хранимые процедуры.
Эффект лемминга. Один сделал так, потому что в его ситуации это дает выигрыш, другой сделал так потому, что видел как делал первый, третий потому что читал, что это может дать выигрыш, четвертый потому что это красиво выглядит, а самое главное - в программу лепится еще один слой и можно с умным видом рассуждать об архитектурных достоинствах...

LelikBolekА что еще?
Ничего. Ни в одном обсуждении мне пока не попалось аргумента, который был бы одновременно достаточно универсальным и мало-мальски объективным (серьезнее уровня "я так привык и мне так нравится и вообще я об этом читал").

Все серьезные аргументы, которые я знаю, выглядят примерно так: в СУБД такой-то из-за такой-то особенности архитектуры вот здесь может быть выигрыш, а в СУБД такой-то такие-то фичи не реализованы и ХП является единственным вариантом решения вот этой задачи.

Вот например вышеназванный "один раз компилятся". Очень популярная легенда, но мне до сих пор никто не назвал СУБД, для которой эта фраза подразумевает реальный выигрыш. Знакомый местным обитателям pkarklin в свое время объяснял мне это на материале MSSQL; в итоге той беседы некто Merle , также известная личность, показал, что даже для MSSQL все обстоит "не совсем так" и если мне не изменяет память (надо бы лезть в поиск) высказал мнение, что в MSSQL ХП в целом не эффективнее запросов.

Чтобы избежать ненужного флейма, уточню формулировку.

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

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

basА как насчет, например, удаления и (или) изменение данных только за текущий месяц? И данных за месяц накапливается много и надо удалить например всЁ за этот месяц, как быть?
Признаться, не понял вопроса. Если нужна операция "удаление всех данных за текущий месяц", скорее всего ее стоит оформить процедурой.

basИли, чтобы юзер не имел прямого доступа к таблицам?
Легко делается без единой ХП. Стоит отметить, что сама постановка вопроса "юзер не имел прямого доступа к таблицам" - кривое решение, пытающееся закрыть проблемы дизайна. Это решение лишь на шаг лучше столь же популярного "юзер вообще не имеет права логиниться на сервер".

LSVОдна из наиболее весомых причин применения сабжа - безопасность.
Хм.

LSVНо я не очень представляю такую систему с 1000таблиц (реальная ситуация). Это же сколько надо процедур ????!!!!!!
В моем случае на примерно 1500 таблиц приходилось около 300'000 строк серверного кода. Сколько это "в процедурах" не могу сказать. Пакетов было.. опять же затруднюсь сказать, что-то между несколькими десятками и до пары сотен по субъективным ощущениям.

gybsonКогда таблиц очень много, есть смысл думать о среднем слое, ...
И прелестях работы с 2*N объектами как альтернативе работы с N объектами...

gybsonметаданных
"Думать"? Они уже есть - select в руки.

PL99Это более технологично - используется однообразный подход к редактированию данных.
То есть другой столь же однообразный подход менее технологичен? Впрочем, тут более интересен вечный конфликт-компромисс между технологичностью единообразия и нетехнологичностью выбора не лучшего инструмента для конкретного случая.

PL99Правильно ли я понимаю Вашу позицию - в системе существует некое количество (часто весьма большое) тривиальных справочников, для которых хранить и вызывать процедуры вставки/удаления/редактирования нецелесообразно?
Хм. Если говорить о моей позиции в целом, то детально формулировать ее будет несколько громоздко, поэтому тезисно:

1. Я полагаю правильным "не плодить сущности без необходимости", а также уверен, что качество системы обратно пропорционально количеству тупого (dumb) кода в ней.

2. Я полагаю, что выбор оптимального решения - не такая простая тема; не слишком формализуемая и определенно не подходящая для рассуждений на пальцах.

3. Я уверен, что неудачное проектирование взаимодействия сервера с клиентом крайне негативно сказывается на качестве системы, на ее основных параметрах: функциональности, эффективности, сопровождаемости.

PL99Редактирование без использования хранимых процедур, IMHO, привязывает к СУБД еще сильнее :-)
Согласен. Если хочется сделать кросссерверное решение, "целиком процедурное API" является довольно привлекательным подходом (разумеется, не для всех задач, но для тех, которые в целом допускают такое решение).

EstetsИменно без всякого "Хм". Одна из задач которые практически невозможно решить с помощью вьюшек это row-level безопасность.
Именно с хм.

softwarerФраза про "ХП один раз компилятся", сама по себе отчасти верная, почему-то превращена в легенду про "один раз компилящиеся ХП в силу этого имеют преимущество над прямыми запросами [которые, видимо, компилятся не один раз]". Именно вот такого эксперимента - выполняем тысячу раз ХП и вот вам офигенное преимущество над выполненным тысячу раз запросом - мне пока никто не показывал и не обосновывал.

EstetsЛично проводил данный эксперимент еще на 9-ке (по моему она была в 1997

Соответственно результатом данного эксперимента было
1-ый вариант 10 секунд (если мне пямять не изменяет)
2-вариант 11 секунд - первый запуск, менее 1 секунды каждый последующий

Правда прошло уже почти 10 лет, последнее время я больше использовал MS SQL. Но не думаю что что-то сильно изменилось.
Удручающая картина. Надеюсь, кто-нибудь из местных Sybase-овцев расскажет, действительно ли все так плохо.

Впрочем, в нарисованной Вами постановке не раскрыт один принципиальный вопрос. В первом варианте 10 секунд - это время первого запуска или время любого из последующих?

EstetsИменно что "любого из последующих" ;(
То есть Вы хотите сказать, что в Sybase принципиально отсутствует кэш планов? Тогда понятно, почему в этом случае процедуры лучше.

Хотя готов подсказать решение "как сделать так, чтобы вышеописанные запросы стали выполняться за 0.1 секунды, в то время как процедура будет продолжать ковыряться по секунде на вызов" :)

EstetsЧто касается хм, то тут мне сказать нечего, скажем каждый остался при своем мнении.
Я тут могу воспользоваться популярным дискуссионным приемом и кивнуть в сторону OEBS. ХП как средство возврата датасетов там практически не используются (не буду говорить "вообще не используются", поскольку для такого проекта очень трудно утверждать с уверенностью), с row-level security проблем не наблюдается.

Estetsа вот в данном случае действительно кэш планов помочь не может, т.к. SELECT ... WHERE doc_date < '20010101' и SELECT ... WHERE doc_date < '20020304' разные селекты.
Хм. Во-первых,

select ... where doc_date < :date и select ... where doc_date < :date

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

Во-вторых, не знаю как в Sybase, а относительно MSSQL Merle рассказывал мне, что сервер ведет себя примерно как Oracle в режиме cursor_sharing = force, то есть: получая указанные Вами два запроса, параметризирует их и использует для них общий план, который строит один раз. Там были свои тонкости, но в первом приближении именно так.

EstetsС OEBS не сталкивался, но работал например с Axapt-ой и сервер приложений прекрасно справляется с row-level security, но все таки сложность написания и поддержки 3-его уровня на мой вглад несколько больше чем, обернуть DML в конструкцию CREATE PROCEDURE AS...
При чем тут сервер приложений? Откуда Вы его придумали и какое отношение он имеет к row-level security в OEBS?

ASCRUS
В целом - совершенно согласен. Единственно, отметил бы, что и вьюшки нужны далеко не всегда.

igorolv + sql-код может оказаться удобнее размещать в хп, а не на клиенте
Впрочем, в половине случаев будет удобнее строго наоборот. Например, вечная боль с попытками совместить хп с пользовательскими фильтрами и сортировками.

igorolv + имея на сервере код хранимых процедур, можно выяснить все использования всех объектов
Как минимум это не есть правда благодаря существованию динамического sql. Если же чуть подумать, окажется, что разницы никакой - на самом деле "все использования всех объектов" в любом случае нужно выяснять в некотором заранее определенном списке мест. Что это за список - код хранимок ли, код клиента ли, конфигурационные таблицы с динамическим кодом - разницы вообще говоря нет.

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

igorolv + все же, в большинстве случаев, быстрее выполнить одну хп с одним "большим" xml-параметром
Жуть. Писать код, которй складывает "большой xml-параметр" только ради того, чтобы кто-то другой писал код, который будет его парсить. Замечательный пример создания сильной статически непроверяемой связи на пустом месте.

igorolvдля сохранения документа, чем вызывать несколько тысяч отдельных sql-запросов, раскладывающих данные в разные таблицы
Хм. Любопытно, с какой стати несколько тысяч отдельных запросов плюс собирание xml плюс парсинг xml плюс логика выбора окажутся быстрее, нежели просто несколько тысяч отдельных запросов. Особенно если учесть возможности оптимизации, доступные при прямой работе.

igorolv + хранимая процедура может поймать и обработать исключение , чтобы кинуть наверх клиенту обработанное на сервере сообщение.
Может. Впрочем, никто не мешает коду исполняемому с клиента сделать в точности то же самое.

igorolvОднако, с фильтрами можно поступить и так
В целом это и есть то, что я назвал "вечная боль". Уродливые неоптимальные запросы, ограниченные функционально фильтры, в целом - решения, по цена/качество рядом не стоящие с обычным запросом. Можно, конечно, но.....

Например, в одной из относительно недавних дискуссий я сказал собеседнику, что могу вставить мастер-детальные данные единственным sql-оператором (речь шла о создании накладной с позициями, кажется). Могу. Даже двумя способами. Но я вряд ли буду так делать в нормальной системе.

igorolvлибо пусть этой задачей занимается клиент.
Хм. Ну это уже капитуляция. Этак весь серверный функционал можно сгрузить на клиента. А с сортировкой опять же - по одному полю еще можно, хотя кривовато, а если хочется по нескольким? Тогда совсем ужасно.

igorolvа как это сделать, если динамический sql формируется из кода, вот таким вот образом ..."where {0}.{1}", @TABLE_NAME, @FIELD_NAME"... (да, при нормальной разработке такого нету, но все же бывает...).
Бывает, и при нормальной разработке.

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

igorolvА мне, например, понадобилось переименовать поле - так я обойду все хранимки и поправлю NEW_NAME as OLD_NAME, а в клиентский код - меня не пустят.
Сомнительно, что не пустят, но если так, это будет большой глупостью. Подобные коллизии существенно ухудшают качество приложения.

igorolvскладывающий код уже написан Microsoft. это Dataset.GetChanges(). парсить его - это openxml - сгенерировать автоматически парсящий код придется только один раз.
Во-первых, в "один раз" я не верю. Придется постоянно следить, чтобы он был согласован с клиентским датасетом. Во-вторых... ладно, не буду высказываться на тему автоматической генерации кода; в случае MSSQL альтернатив к сожалению скорее нет.

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

igorolvВозможно, я недостаточно четко пояснил...
ОДИН РАЗ собирание xml на клиенте + ОДНА процедура + ОДИН ее вызов на сервере + openxml на сервере будет работать быстрее ЧЕМ несколько тысяч отдельных запросов на сервер.
А кто мешает ОДИН РАЗ передать на сервер скрипт из нескольких тысяч запросов? Это определенно будет работать не дольше, нежели ОДНА процедура, выполняющая внутри себя несколько тысяч отдельных запросов.

Возможно, я Вас не понимаю из-за незнания, что такое openxml.

Впрочем, никто не мешает мне выполнить с клиента array dml. То есть передать на сервер один оператор insert..values и несколько тысяч строк данных, которые должны через него пройти. Это намного быстрее, чем выполнять несколько тысяч insert поотдельности.

igorolvпроблема в том, что имеется несколько разных клиентских приложений.
Несколько разных клиентских приложений, входящих в один программный комплекс, имеют полную возможность пользоваться общими библиотеками. Соответственно, для них нет разницы, вызвать ли общую хранимку или общую функцию из dll-ки.

Что касается нескольких полностью независимых клиентских приложений, авторства разных групп разработчиков итп, то я не встречал случая, чтобы они активно пользовались общим ХП-api. Максимум, такое изредка случается при кастомизации какого-нибудь стандартного инструмента, например генератора отчетов.

igorolvНе считая уже большого числа пользователей-программистов, предпочитающих общаться с сервером из Management Studio.
Есть такое. В том числе им довольно часто приходится выполнять уникальные операции, ХП для которых просто нет.

igorolv В общем, и динамический sql и хранимые процедуры имеют как свои плюсы, так и минусы. А что выбрать - зависит от специфики проекта.
Безусловно.

igorolvВ нашем случае выгоднее оказались хранимые процедуры. В другом случае - динамический sql. Просто добавил несколько аргументов в пользу хранимок.
Я к тому, что сами аргументы не все.. однозначны.

igorolv- Ну нету у нас, разработчиков SQL Server, например, bind-переменных.
Насколько я знаю, есть переменные, которые можно использовать тем же макаром. Может быть не очень красиво, но вроде работает как надо. Хотя вроде Merle убеждал меня, что сервер сам неплохо разбирается с параметризацией запросов.

igorolvконструкции вида "x.ID = @ID or @ID is null" - уродливые - пожалуй, но неоптимальными они становятся
Становятся. Фильтры с OR в общем случае плохо оптимизируются. Главная причина - вообще говоря, оптимизатор должен строить и использовать уже не один план на запрос, а 2^N, где N - количество таких вот условий. Но признаться мне неизвестны оптимизаторы, которые бы так поступали.

Далее, приведенные Вами в целом рассуждения резюмируются одной фразой: можно на пустом месте натворить себе кучу геморроя и в конце концов добиться примерно той же функциональности ценой больших тормозов. Практической выгоды при этом никто не получает; теоретически получаемая здесь независимость на практике накрывается медным тазом появившихся паразитных зависимостей.

igorolvИногда, если хочется отсортировать данные по нескольким полям, это означает довольно большой объем запрошенной с сервера выборки.
Оригинальная точка зрения. Никогда бы не подумал, что объем запрошенной выборки зависит от сортировки.

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

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

igorolvКроме того, имеет место некоторый "шкурный" интерес - "сервер отдаст данные клиенту - а клиент пусть их у себя в памяти крутит как хочет".
Это не "шкурный" интерес, а жуткая неэффективность.

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

igorolvКлиентов много и все сплошь - толстые, а сервер - один... Выдал им их данные - пусть сами их отображают как хотят, причем меняя это отображение для клиента не спрашивая "совета" сервера.
В общем, я не зря упомянул раньше термин "капитуляция". У Вас выходит замкнутый круг: сервер не справляется со своей работой, поэтому его функции перегружаются на клиента. Ради этого на клиента приходится тащить кучу лишних данных (лишних - поскольку в противном случае клиент не стал бы их фетчить), что собственно снова напрягает сервер.

igorolvА дальше по ОДНОМУ insert-у на КАЖДУЮ ТАБЛИЦУ данные insert into ... select ..from openxml
Понятно. Значит, по эффективности должно быть примерно эквивалентно array dml, если не считать собственно времени на возню с xml.

igorolvили же ОДИН раз С КЛИЕНТА переданный НАБОР нескольких тысяч insert-ов.
Кстати, не обязательно несколько тысяч. Я не знаю, как лучше в MSSQL, но почти уверен, что xml - не единственный в нем способ массовой вставки.

igorolv1) Если уникальные операции связаны с чтением данных - естественно, либо сами пишут хранимку и отправляют разработчику БД для проверки и включения в модель,
Уникальные операции. Нечто, что нужно выполнить один раз. В модели оно нафиг не нужно, потому что скорее всего больше никогда не потребуется.

Just for example, пришла ко мне когда-то девушка и сказала: у нас баланс не сходится вот на эту сумму. Подсчитай пожалуйста, вот из таких вот оплаченных счетов, какие именно в сумме дадут это число?

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

igorolv"OR" - сама по себе, естественно, конструкция которая может очень плохо сказаться на производительности. Однако не в данном конкретном случае.
Дело в том, что конструкция "x.ID = @ID or @ID is null" оптимальнее, чем x.ID = isnull(@ID, ID).
Вопрос в том, что при полноценном формировании фильтра не нужно ни того, ни другого. В этом случае в запрос либо попадает x.ID = :ID либо не попадает ничего вообще; оба варианта более эффективны, нежели приведенные выше.

Насчет замены OR на UNION я в курсе, Oracle ее делает. Но и UNION уступает в эффективности вышеприведенной строке.

igorolvИмелось в виду следующее - когда пользователь меняет сортировку, иногда он хочет чего-то разыскать с помощью этой сортировки (упорядочить для себя данные с целью облегчения визуального поиска). Т.е. "если понадобилась сортировка" => значит, выборка большая.
О! Именно. Теперь давайте считать. У нас на клиенте есть, допустим, 50 строк. Одно дело - дофетчить на него остаток "большой выборки". Другое дело - послать на сервер новый запрос, в результате которого снова вернется 50 строк. С ситуацией, когда первое быстрее, я столкнулся единственный раз в жизни.

igorolvЭто уже вопрос, используется в проекте или нет постраничная выборка. У этого решения есть как свои плюсы (скорость), так и минусы (более сложно для реализации,
Ээ... не понял. Мне казалось, это везде делается автоматически.

igorolvсогласованность чтения данных по порциям
Хм. Судя по этой фразе, Вы говорите о многократных запросах для выбора разных страниц. Я же имею в виду фетч из одного курсора. Правда, в соседней теме вроде выяснили, что в MSSQL тут могут быть проблемы с неконсистентным чтением при read committed, но они могут быть в любом случае.

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

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

igorolvВ ЛЮБОМ случае смена сортировки на клиенте будет быстрее, так как данные у него уже в памяти - не нужно за ними бегать на сервер отдельным запросом.
Не согласен с постулатом и соответственно с выводом. В памяти не "данные", а "первый небольшой кусок данных". Если сменить сортировку, нужно качать все данные - сортировать "уже скачанный кусок" глупо и нелепо [ладно, я готов согласиться, что есть специфические случаи, но в общем...]

igorolvА изначальная установка сортировки, есть подозрение, во МНОГИХ случаях будет все равно быстрее на клиенте.
Не понял.

Не знаю как у Вас, а у меня есть очень простая возможность сравнить эти варианты. Запускаю PL/SQL Developer, выполняю


вижу результат через 0.25 секунды. Теперь выполняю


и жму его сортировку на клиенте - получаю 11.4 секунды на фетч данных и около двух секунд на собственно сортировку в памяти.

igorolv(Кстати, сочетание постраничной выборки И сортировки на сервере - ой, не уверен что ВСЕГДА загрузка списка договоров из 10000 окажется быстрее чем загрузка "первых 30 договоров, отсортированных в определенном порядке").
Ээ.. не понял, как это сочетается с Вашей позицией. Я как раз уверен, что второй вариант будет много быстрее.

igorolvРезюмируя, не ВСЕГДА сортировка на сервере предпочтительнее сортировки на клиенте.
Теоретически - не всегда. Практически я столкнулся с предпочтительностью сортировки на клиенте один раз в жизни; это была аналитическая система, которую характеризовали тяжелые, долгие запросы и небольшие результирующие выборки (порядка десятков секунд и сотен записей соответственно).

Соответственно, я готов согласиться насчет "выбора в конкретном случае", с помаркой, что этот случай редкий. Теперь, если вернуться к основному обсуждаемому вопросу, получим, что в некоторых конкретных случаях у ХП не будет геморроя с поддержкой сортировки (в остальных, имхо в подавляющем большинстве - будет).

igorolvВ MS SQL таблица не может быть параметром хранимой процедуры или запроса,
.. в целом я определенно не готов говорить об оптимальном для MSSQL пути, Вам виднее.

igorolvЗакрывать вообще структуру базы от всех и давать вместо нее набор хранимок - вряд ли верное решение.
OK, к этому утверждению мне и хотелось прийти.

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

igorolvРезюмируя все вышесказанное мною: ГЛАВНОЕ, в проекте должно быть некоторое единое место, где хранится весь sql-код (либо отдельные составляющие, из которых он складывается).
Вот под этим я готов подписаться, с некоторой оговоркой насчет того, что именно понимать под "единым местом".

С моей точки зрения, в технологии довольно часто делают ошибку, путая разделение полномочий между разработчиками (тот пишет запросы, тот - гуй) и архитектуру/размещение приложения. Это разные вещи; скажем, если я пишу запросы - я пишу запросы. Но в зависимости от архитектуры приложения они могут быть обернуты в хранимки и размещаться на сервере, а могут быть обернуты в клиентские процедуры или компоненты. Интерфейс моего взаимодействия с разработчиком гуя в обоих случаях одинаков: тот обращается к некому объекту и получает от него датасет (в его клиентском представлении).

igorolvВариант со списком хранимок далеко не самый плохой. Скажем так, он ВПОЛНЕ ДОПУСТИМЫЙ.
Безусловно. Я здесь подчеркиваю, что он один из допустимых, а не единственно допустимый. Если помните, эту часть беседы мы начали с поиска мест использования; я хочу подчеркнуть, что хранимки здесь не дают преимущества над другими вариантами.

igorolvНе уверен, что пользователю понадобится сортировка по object_id
Хм. Стоит ли придираться к таким мелочам? Для любой колонки или колонок эффект будет аналогичным.

igorolv
-- Выберем первые 30 договоров, отсортированые по названию типа документа
select top 30 *
Уже не понял. Зачем выбирать 30? Это в тему страничного считывания? Неужели меня обманули, когда говорили, что в MSSQL есть нормальный неполный фетч?

igorolvПонятно, что тормоза идут от top 30, но от этого же не легче.
Как раз легче. Я не понимаю, зачем Вам понадобился этот top 30.

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

igorolvЭто я все к чему - стоимость сортировки на сервере зависит от того, что находится вышет order by. А сортировка на клиенте - не зависит. Производительность зачастую "проявляет" себя как раз на сложных тяжелых запросах. И отягощать их order by-ем не хочется.
Согласен, но тут есть один момент. Запросы, выводимые пользователю в гридах (или аналогичных инструментах с возможностью сортировки) как правило очень простые, и сортировка их не тормозит. Сложные запросы типичны для "внутренностей" ИС, но там сортировка пользователем не настраивается, а как правило и не нужна.

igorolvНа клиенте отсортировать в памяти небольшую (<= 10000) выборку не так уж и сложно-долго. А часть нагрузки с сервера снимается.
На сервер при этом добавляется нагрузка чтения всех данных и передачи их на клиента, в то время как для сортированной выборки сервер может прочитать только небольшую часть данных.

igorolvРезюмируя - не так уж редки ситуации, когда отдать на клиент всю выборку бывает для сервера выгоднее, чем предварительно ее сортировать и отсылать только часть. Это, в частности, зависит от архитектуры системы.
Думаю, не стоит спорить о числовых значениях "не так уж редки". Обращу внимание на другую сторону вопроса: если мы делаем запросы с клиента, мы полностью вольны в выборе где именно и как именно сортировать. Если же мы идем через ХП, серверная сортировка осложняется - а "не так уж редки" случаи, где именно она будет предпочтительной.

На всякий случай еще раз отмечу, что по большинству реально значимых вопросов мы с Вами явно согласны. Я исключительно занудствую :)

PL99Однажды представитель одного заказчика выразил, на мой взгляд, довольно верную идею - "пусть будет безобразно, но однообразно" :-)
Я согласен с реакцией igorolv :-)

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

PL99IMHO, однообразие того стоит и в этом смысле мне нравится "жесткий процедурный API"
Жесткий процедурный API в общем случае не позволяет получить изделие приемлимого с моей точки зрения качества. Что для меня закрывает вопрос о нем как о единственном и универсальном методе.

PL99Гм... Как только я создаю "клиентскую компоненту", у разработчика гуя работы больше не остается.
Не вижу оснований для такой точки зрения. Работа у него остается ровно та же самая: визуализировать данные, отстроить пользовательский интерфейс, в нужные моменты вызывать указанные методы. Что внутри этих методов - ХП или "запросы с клиента" - заведомо не должно его волновать, это базовый принцип инкапсуляции.

PL99Скажем так, если я занимаюсь написанием запросов в клиенте, то конечно, я могу отдать этот объект на дальнейшую доработку разработчику гуя, но, IMHO, не совсем правильно, когда с одним и тем же объектом работают два человека. Хотя, разумеется, возможны варианты ;-)
На какую дальнейшую разработку? Один разработал, другой использует, совершенно нормальная картина.

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