 |
|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vladimir Pavlikov 2:5020/400 09 Oct 2001 15:49:05 To : Victor Metelitsa 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> <9pkeuo$bb7$1@host.talk.ru> ax.com> <3BC290A2.4020105@cssc.tat.ru> From: "Vladimir Pavlikov" <pvv@soil.msu.ru> Hello! "Victor Metelitsa" <vvm@cssc.tat.ru> wrote: > > Текст ниже привязан к конкретному серверу, или "вообще"? > >>1. Процедура, в отличие от запроса, не может быть переписана оптимизатором > >>по его усмотрению, она заранее задает "план доступа". А у программиста нет > >>данных, которыми распологает оптимизатор. > > > > Hе согласен. И там, и там sql текст, и оптимизатор может его соптимизировать > > (или нет:). "Переоптимизировать" - это второй вопрос, зависит от формата > > хранения и др. Собственно, это касается и п2. > Вот простенький пример. > CREATE VIEW TC AS > SELECT * FROM TA > UNION ALL > SELECT * FROM TB; > > > Тогда DB2-шный оптимизатор перепишет > > SELECT * FROM TC WHERE fa=? > > как > > SELECT * FROM TA WHERE fa=? > UNION ALL > SELECT * FROM TB WHERE fa=? > > Теперь можно применять индексы, параллелить и т.п. > Теперь возьмем другой экстремальный случай - Interbase, как минимум, до > 5-й версии не умел создавать VIEW с UNION ALL. Однако в нем можно > реализовать то же самое на хранимой процедуре. Hо как ты представляешь > автоматическую оптимизацию хранимой процедуры a la Interbase подобно > тому, что я привел для VIEW выше, в общем случае? При чем тут "хранимой процедуры a la Interbase"? Последний хранит про- цедуры в уже скомпилированном виде - преобразовывать нечего. У DB2 процедуры имеют совсем другой "a la", поэтому я сразу спросил о конкрет- ном ли сервере идет речь. SQL-текст _можно_ "собирать" и оптимизировать совместно, а конкретный сервер DB2 обсуждать и не собирался. > Вместо UNION ALL можно было взять что-то другое. Оператор выборки в DB2 > самый мощный [из известных мне]; один запрос нередко выполняет такую > работу, какую другие SQL-сервера неспособны выполнить без SP и/или > временных таблиц. Hа эту тему дискутировать совершенно не хочется. Hо, поскольку подоб- ные утверждения звучали неоднократно - просто выскажу свое мнение, для равновесия :) 1. Километровые запросы не есть хорошо, даже если это всего лишь возможность 2. Их _необходимость_ (использование SP сильно "опускает" хваленый оптимиза- тор) есть плохо. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/64886cb0c328.html, оценка из 5, голосов 10
|
|
|