Наистина зависи, имах ситуации, в които подобрих някои заявки, като използвах подзаявки.
Факторите, които ми е известно са:
- ако подзаявката използва полета от външна заявка за сравнение или не (корелирани или не)
- ако връзката между външната заявка и подзаявката е покрита от индекси
- ако няма използваеми индекси в обединяванията и подзаявката не е корелирана и връща малък резултат, може да е по-бързо да се използва
- Срещал съм също така ситуации, при които преобразуването на заявка, която използва поръчка от, в заявка, която не я използва, и след това превръщането й в проста подзаявка и сортиране, което подобрява производителността в mysql
Както и да е, винаги е добре да тествате различни варианти (моля с SQL_NO_CACHE) и превръщането на корелирани заявки в обединения е добра практика.
Дори бих отишъл толкова далеч, за да го нарека много полезна практика.
Възможно е, ако корелираните заявки са първите, които ви идват на ум, че не мислите предимно по отношение на операциите на набора, а предимно по отношение на процедурните операции и когато работите с релационни бази данни, е много полезно да приемете напълно набора гледна точка на модела на данните и трансформациите върху него.
РЕДАКТИРАНЕ:Процедурни срещу релационни
Мисленето от гледна точка на множество операции срещу процедурни се свежда до еквивалентност в някои изрази от алгебра на множеството, например изборът върху обединение е еквивалентен на обединение на селекции. Няма разлика между двете.
Но когато сравните двете процедури, като например да приложите критериите за подбор към всеки елемент от съюз с създаване на съюз и след това приложите подбор, двете са ясно различни процедури, които може да имат много различни свойства (например използване на CPU, I/O, памет).
Идеята зад релационните бази данни е, че не се опитвате да опишете как да получите резултата (процедура), а само това, което искате, и че системата за управление на базата данни ще реши най-добрия път (процедура) за изпълнение на вашата заявка. Ето защо SQL се нарича език от 4-то поколение (4GL) .
Един от триковете, които ви помагат да направите това, е да си напомните, че кортежите нямат присъщ ред (елементите на набора са неподредени). Друг осъзнава, че релационната алгебра е доста изчерпателна и позволява превод на заявки (изисквания) директно в SQL (ако семантиката на вашият модел представя добре проблемното пространство или с други думи, ако значението, прикрепено към името на вашите таблици и връзки, е направено правилно, или с други думи, ако вашата база данни е проектирана добре).
Следователно не е нужно да мислите как, а само какво.
Във вашия случай това беше просто предпочитание пред свързаните заявки, така че може да се окаже, че не ви казвам нищо ново, но вие подчертахте тази точка, оттук и коментарът.
Мисля, че ако сте напълно удобни с всички правила, които преобразуват заявките от една форма в друга (правила като например дистрибутивност), че не бихте предпочели корелирани подзаявки (че ще видите всички форми като равни).
(Забележка:по-горе се обсъжда теоретичната основа, важна за дизайна на база данни; на практика горните концепции се отклоняват - не всички еквивалентни презаписвания на заявка непременно се изпълняват, тъй като бързите, клъстерирани първични ключове правят таблиците да наследяват реда на диска и т.н.... но тези отклоненията са само отклонения; фактът, че не всички еквивалентни заявки се изпълняват толкова бързо, е несъвършенство на действителната СУБД, а не на концепциите зад нея)
