 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 05 Oct 2001 18:11:15 To : Alexey Fisson Subject : Re: ms sql server vs. ibm db2 -------------------------------------------------------------------------------- ax.com> <9pfi9s$gb7$1@gavrilo.mtu.ru> <9phds3$ccf$1@host.talk.ru> ax.com> <9pi7d7$2f6$1@gavrilo.mtu.ru> From: "Vladimir Pavlikov" <pvv@soil.msu.ru> Hello! "Alexey Fisson" <favn@csi.ru> wrote: Текст ниже привязан к конкретному серверу, или "вообще"? > 1. Процедура, в отличие от запроса, не может быть переписана оптимизатором > по его усмотрению, она заранее задает "план доступа". А у программиста нет > данных, которыми распологает оптимизатор. Hе согласен. И там, и там sql текст, и оптимизатор может его соптимизировать (или нет:). "Переоптимизировать" - это второй вопрос, зависит от формата хранения и др. Собственно, это касается и п2. > 2. Выполнение процедуры вследствие заданной последовательности действий не > может быть распараллелена по процессорам/узлам сервера, не будет в таком > объеме параллельного ввода/вывода на дисках. Запрос же параллелится. Для > ядра СУБД в принципе не доступна логика процедуры, в отличие от логики > запроса. Оптимизаторы не оптимизируют процедуры, т.е. действие будет > выполняться с точки зрения СУБД как последовательная череда мелких запросов, > вместо одного крупного, выполнение частей которого возможно одновременно. > Более того, оптимизатор не может заранее оценить время выполнения процедуры > и сбалансировать нагрузку при ее параллельном выполнении с чем-то еще. > 3. Из процедуры недоступны операции с индексами, которые может выполнять > только сам сервер. Операция объединения, например, может быть существенно > ускорена с помощью AND над индексами таблиц. Если же таблицы последовательно > обходятся процедурой - облом. > 4. SQL как таковой создан для абстрагирования данных от алгоритмов. Hу > декларативный он. :) А работа с данными с помощью процедур куда быстрее в > сетевой модели - уж там-то и индексы доступны, и ядро под это заточено. Это > совсем другая идеология. Сеть - это отдельная песня, ее трогать не будем. Мне кажется, что пп 3 и 4 противоречат друг другу : явное использование индексов тоже грубо противоречит декларативности, недаром они в языке не упоминаются. И, опять же, не вижу причин, по которым сервер не может использовать индексы при отработке процедуры. > 5. DB2 кэширует схему доступа и результаты каждого запроса. То есть один раз > введенный запрос в следующие разы скорее всего уже не будет пропахиваться > оптимизатором, компилится в схему доступа, выборка данных с большой > вероятностью произойдет из кэша. Выигрыш в производительности весьма > заметный, видно невооруженным глазом. А процедуру как кэшировать, с ее > непонятной СУБД логикой? Да в DB2 даже объявляя UDF на C или Java, надо > написать - зависит ее результат от параметров или нет, чтобы DB2 могла не > дергать ее лишний раз. При написании процедуры (когда без нее можно > обойтись) ты берешь на себя функциональность самой СУБД. И то, что некоторые > СУБД вынуждают это делать, не значит, что это есть хорошо. :) Если все предыдущее касалось только db2 - я пас. Этот сервер ориентирован именно на запросы, и обсуждать тут процедуры несколько неуместно. > Фуф! Убедил? А надо? :) В твоем тексте все касается только оптимизации и производитель- ности. Что важно, но есть и группа других вопросов - модифицируемость ( с учетом реальной изменчивости задач и условий), "инкапсуляция" и другие. С их учетом очень многое стоит делать только на SP/View :) И эта часть зависит от задач гораздо больше, чем от конкретных реализаций серверов. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/64883c59d735.html, оценка из 5, голосов 10
|
|
|