N∞kdy je zajφmavΘ pozorovat, jak se dajφ jistΘ triky vzneÜen∞ pojmenovat. P°esn∞ tak je tomu se syntaxφ °φzenou optimalizacφ. P°edpoklßdß se zde, ₧e u₧ivatel zahrne informaci pro optimalizaci do textu dotazu samotnΘho, tj. p°inutφ vlastn∞ optimalizßtor provΘst jist² provßd∞cφ plßn. V n∞kter²ch relaΦnφch S╪BD je nap°. znaΦn² rozdφl v provedenφ nßsledujφcφch dvou dotaz∙:

SELECT * FROM FILM

WHERE FILM.CENA > 8 AND FILM.ZEM╠ = 'Rumunsko'

a

SELECT * FROM FILM

WHERE FILM.ZEM╠ = 'Rumunsko' AND FILM.CENA > 8

Optimalizßtor p°edpoklßdß, ₧e podmφnka s nejmenÜφ selektivitou (podφl poΦtu vybran²ch °ßdk∙ ku vÜem °ßdk∙m) je umφst∞na jako prvnφ, tj. prvnφ dotaz z°ejm∞ povede k velmi pomalΘmu vyhodnocenφ, druh² dotaz bude naopak rychlejÜφ, p°edpoklßdßme-li, ₧e je jen malΘ mno₧stvφ rumunsk²ch film∙ v databßzi filmovΘ distribuce a b∞₧nou cenu filmu v∞tÜφ ne₧ 8 mil. (KΦ).

Nev²hody tohoto postupu jsou nespornΘ. U₧ivatelskß aplikace se stßvß zßvislß na konstrukci vyhodnocovacφho algoritmu. U₧ivatelΘ ne°φkajφ pouze "co cht∞jφ", ale i "jak to zφskat", co₧ odporuje zßkladnφ myÜlence pou₧itφ S╪BD. Navφc, zm∞nφ-li se nap°. velikosti relacφ, je nutnΘ ji₧ "vylad∞n²" dotaz znovu ruΦn∞ optimalizovat. DalÜφm problΘmem m∙₧e b²t, ₧e °ada aplikacφ automaticky generuje SQL p°φkazy, p°iΦem₧ nemusφ b²t jasnΘ, na jakΘm databßzovΘm stroji budou tyto p°φkazy zpracovßny a hlavn∞ nad jakou databßzφ budou provßd∞ny. Nelze tedy p°edem ruΦn∞ za°φdit vhodnou syntaxi dotazu.

DalÜφ p°φpad, kdy u₧ivatel m∙₧e pozitivn∞ ovlivnit vyhodnocenφ dokonce v p°φpad∞, kdy existuje optimalizßtor, je v dotazu SQL p°i pou₧itφ OR za WHERE. Uva₧ujme dotaz "VypiÜ z relace FILM n-tice t²kajφcφ se film∙ z VelkΘ Britanie natoΦen²ch po roce 1988 nebo n-tice t²kajφcφ se film∙ z Rumunska".

SELECT * FROM FILM

WHERE (ROK > '1988' AND ZEM╠ = 'Velkß Britanie') OR ZEM╠ = 'Rumunsko'

Optimalizßtor bude mφt tendenci zpracovat relaci FILM sekvenΦn∞, dokonce i kdy₧ existuje index pro atributy ZEM╠ i ROK. Jde o strategii, ₧e od jistΘ slo₧itosti logickΘ podmφnky ji₧ optimalizßtor nehledß ₧ßdn² ôinteligentnφ plßnö, ale p°istupuje ke zpracovßnφ hrubou silou, tj. sekvenΦn∞. Vhodn∞jÜφ je proto pou₧φt UNION a zapsat dotaz ekvivalentn∞ jako

SELECT * FROM FILM

WHERE (ROK > '1988' AND ZEM╠ = 'Velkß Britanie')

UNION

SELECT * FROM FILM

WHERE ZEM╠ = 'Rumunsko'

Optimalizßtor z°ejm∞ pou₧ije indexy pro ka₧d² poddotaz.

Jin² trik lze pou₧φt v p°φpad∞, ₧e k vφce atribut∙m v podmφnce dotazu existuje index. Optimalizßtory se Φasto chovajφ tak, ₧e pou₧ijφ vφce index∙ je tehdy, kdy₧ podmφnky obsahujφ pouze konjunkci rovnostφ, nap°. ROK = '1988' AND ZEM╠ = 'Velkß Britanie'. V ORACLE serveru verze 6 existovalo omezenφ na pou₧itφ nejvφce 5 takov²ch index∙ pro jeden dotaz. Jsou-li ovÜem n∞kterΘ podmφnky jinΘho typu, vybere se index pouze jeden. Uva₧ujme dotaz

SELECT * FROM FILM

WHERE (ROK = 1988 AND ZEM╠ LIKE 'No%')

Proto₧e film∙ ze zemφ Norsko, Nov² ZΘland apod. je z°ejm∞ mΘn∞ ne₧ vÜech film∙ z roku 1988, cht∞li bychom p°inutit optimalizßtor, aby vybral index pro atribut ZEM╠. Toho se docφlφ syntaktickou variantou dotazu

SELECT * FROM FILM

WHERE (ROK = 1988 + 0 AND ZEM╠ LIKE 'No%')

Vyu₧ije se toti₧ toho, ₧e optimalizßtor nepou₧ivß index pro atribut porovnßvan² s v²razem.

Zkusme nynφ dotaz pou₧φvajφcφ SELECT bez klauzule WHERE, nap°. ôNajdi zem∞, jich₧ ₧ßdn² film se zrovna nehrajeö.

SELECT ZEM╠

FROM FILM

WHERE FILM.JM╔NO_FILMU NOT IN (SELECT JM╔NO_FILMU

FROM P╪EDSTAVEN═)

I kdy₧ existuje index na JM╔NO_FILMU v P╪EDSTAVEN═, nevyu₧ije se, proto₧e JM╔NO_FILMU se v relaci P╪EDSTAVEN═ nevyskytuje za WHERE. Pou₧itφ indexu lze vynutit p°φkazem

SELECT ZEM╠

FROM FILM

WHERE NOT EXISTS (SELECT P╪EDSTAVEN═. JM╔NO_FILMU

FROM P╪EDSTAVEN═

Takov² dotaz je ovÜem hnφzd∞n² a je nynφ otßzkou, jakou strategiφ se bude vyhodnocovat. N∞kterΘ hnφzd∞nΘ dotazy lze p°evΘst na zßpis pouze s jednφm SELECT p°φkazem.

Ka₧d² uhßdne, ₧e se syntaxφ °φzenou optimalizacφ m∙₧eme dostat do pokus∙ ne nepodobn²ch alchymii.N∞kterΘ firmy proto p°φmo poskytujφ nßvod, jak psßt SQL dotazy, jakou formu syntaxe zvolit, aby dotaz byl vyhodnocen co nejefektivn∞ji. Existujφ ovÜem takΘ p°φstupy, kdy lze pro dan² dotaz p°φmo navrhnout plßn vyhodnocenφ. P°i ô₧ivotn∞ d∙le₧it²chö dotazech m∙₧e takov² p°φstup mφst sv∙j dobr² smysl.