Алексей К модСмысл очень простой - разгрузить процессоры сервера БДДавайте вообще уберём процессор с сервера, оставим один HDD. :-))

Идея не нова, и более того, уже реализована. В частности нонфигурация, где БД назмещена в NAS, а СУБД на отдельном сервере. NAS обеспечивает доступ к данным на уровне файлов, СУБД, на уровне реляционных, объектных и т.п. отношений.

Sergey OrlovМожет быть не в тему, но все-таки.
Ни для кого не секрет, что SQL-ная версия 1С 7.7 реализована в виде толстого клиента, при этом мы имеем возможность создания и использования в ее интерфейсе запросов в самом SQL-сервере, т.е. как тонкого клиента.
так вот практика: время создания специфического отчета средствами самого клиента, а там были и расчеты и группировки и т.д., резко колебалась и естественно зависела от компьютера на котором он запускался, от минуты до 20 минут, после оформления его в виде вызываемой ХП, пользователь получал его в течении 20 секунд и при этом не было зависимости от компьютера пользователя, по крайней мере на глаз...

Ясен пень, что скорость завивит от оборудования. Серверы приложений и созданы, чтобы с одной стороны разгрузить СУБД, с другой стороны не нагружать клиента, ресурсы которого могут оказаться недостаточными для решения задачи.

Bogdanov AndreyНе знаю как в MSSQL, но в Oracle возвращение данных с помощью ХП - это два запроса вместо одного. ...
Ну так вот выполнение первого из этих запросов требует ровно тех-же действий, что и выполнение обычного select (правда чем у Alex_Toms различаются п.1 и п.2 я не понял). Ну а второй запрос (тот что внутри ХП), естественно, уже скомпилирован. А кстати, повтороное выполнение одного и того же запроса (что вызова ХП, что select) уже не приводит к повторному анализу и оптимизации - производится тупое сравнение строк с имеющимися в кэше.

ХМ. Я не знаю, что вы понимаете под компиляцией SQL запроса, но во время компиляции ХП PL/SQL, происходит только проверка синтаксиса и семантики статического запроса (наличие и доступности таблиц и колонок) в объёме необходимом для создания соответствующего запросу p-кода, например структуры буфера для выборки строк. Исполнимый код SQL запроса не создаётся. На этапе выполнения текст запроса восстанавливается и в почти исходном виде отправляется в SQL машину для разбора, построения плана (т.е. исполнимого кода) и выполнения, т.е. по сути компилируется повторно, но уже полностью.

Среди разработчиков Oracle бытует миф, о магическом ускорении статических SQL запросов по сравнению с динамическими. Считается, что ускорение связано с некой компиляцией SQL запроса в ХП. Но, источник этого мифа не компилятор, а кэш курсоров PL/SQL, который позволяет исключить повторный разбор (parse) SQL запроса, если он выполнялся ранее. С тем же успехом программист может сам отслеживать часто используемые курсоры и не закрывать их без нужды. В добавок компилятор причёсывает SQL запросы, удаляя из них ненужные коментарии, и прочие пробельные символы, переименовывает переменные привязки, поднимает регистр идентификаторов, понижая вероятность жёсткого разбора из-за несущественных различий в тексте разных запросов.

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

С кэшем или без оного в общем случае каждая транзакция видит своё состояние БД отличное от других транзакций, ибо изоляцию транзакций никто не отменял. Только в БД открытой на чтение (или блокированной) все транзакции видят один и тот же образ данных.

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