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