Принципы хорошие, но все это приходит с опытом. Без знания конкретной технологии это не поможет. В первом примере, с cte: не ощущается что есть понимание того, что cte это синтаксический сахар, который разворачивается на одном из ранних этапов исполнения (иначе откуда этот опус: "CTE имеет свои meta данные, что позволяет оптимизатору обрабатывать эти данные как отдельную таблицу. Это сильно может ускорить работу запроса."??)
Второе, если так сильно хотелось cte, и если джоины теже самые в агрегациях и деталях (а похоже что так), то это проще решить (обычно решается) каскадными cte: то что у Вас основной запрос — это первая cte, тут и фильтр - один раз; то что у Вас основной запрос это вторая cte- агрегация из первой from cte1 (поэтому называется каскадной). Основной запрос (или cte3): cte1 join cte2. Максимально наглядно и понятно, причем как программисту так и оптимизатору!
Но, да, безусловно, SQL это наверное самое неудачное место применения этих принципов!)
Принципы хорошие, но все это приходит с опытом. Без знания конкретной технологии это не поможет. В первом примере, с cte: не ощущается что есть понимание того, что cte это синтаксический сахар, который разворачивается на одном из ранних этапов исполнения (иначе откуда этот опус: "CTE имеет свои meta данные, что позволяет оптимизатору обрабатывать эти данные как отдельную таблицу. Это сильно может ускорить работу запроса."??)
Второе, если так сильно хотелось cte, и если джоины теже самые в агрегациях и деталях (а похоже что так), то это проще решить (обычно решается) каскадными cte: то что у Вас основной запрос — это первая cte, тут и фильтр - один раз; то что у Вас основной запрос это вторая cte- агрегация из первой from cte1 (поэтому называется каскадной). Основной запрос (или cte3): cte1 join cte2. Максимально наглядно и понятно, причем как программисту так и оптимизатору!
Но, да, безусловно, SQL это наверное самое неудачное место применения этих принципов!)