|
|
| Тема |
 Re: По принцип има [re: TPECKATA] |
|
| Автор |
wqw (АзСъмЖив) |
|
| Публикувано | 03.04.07 18:55 |
|
|
|
Какво значи "JOIN-а се извършва винаги преди да се проверят WHERE условията."? Стъпките на execution plan-а не са 1-към-1 със самата заявка. Ако си представим заявката като дърво, на което листа са обектите от базата (обикновено таблици или индекси), предикатите от WHERE клаузите (да, няколко) и ON клаузите се "избутват" по-близо до листата, като трансформациите с които това се прави гарантират еквивалентност на резултата.
Обърни внимание на еквивалентност. Естествено че предикат от ON клаузата на OUTER JOIN не може да слезе в WHERE клаузата -- просто двете заявки няма да са еквивалентни. Но ето тези две еквивалентни заявки
SELECT *
FROM authors a1
JOIN authors a2
ON a1.au_id = a2.au_id
SELECT *
FROM authors a1
CROSS JOIN authors a2
WHERE a1.au_id = a2.au_id
... генерират абсолютно еднакъв резултат и още повече -- абсолютно еднакъв execution plan.
Прочетох втори път мнението ти и това което си написал именно "на теория" не е вярно. На практика обаче е възможно е да има скодоумни db engine-и, които действат по описания от тебе начин :-))
А в примера от Additional Criteria in the JOIN Clause е ясно че заявките не са еквивалентни -- това с предикат в ON на LEFT JOIN няма нищо общо със същия предикат в WHERE клаузата. Къде остава да си говорим за performance въобще!
Виж това за "рекурсивния" JOIN изби рибата :-)) Хората се затрудняват да ползват alias-и явно. Но и там няма проблем за engine-а да оптимизира (виж горните "рекурсивни" заявки). Btw, за рекурсивност можем да говорим само в CTE от ANSI SQL'99 (или MSSQL2005).
Относно така споменатите SQL разширения, които престават да са декларативни. Толкова по-зле за тях! Колкото по-декларативен е езикът, толкова по-добре engine-а ще оптимизира execution плана. Това е идеята -- vendor-ите да се "състезават" по съвършени engine-и, а не да ме дърпат във vendor lock с proprietary extension-и за обхождане на йерархии (oracle) или парсване на XML (MS).
cheers,
</wqw>
| |
| |
| 
|
|
