StaxELSE не подойдет?

Я случайно опубликовал один из размышлизмов.

DshedooКак мне кажется, если этот запрос и можно хорошо оптимизировать, то только через UNION.
1. Оптимизация невозможна без конкретной цели и конкретного окружения.
2. Если, к примеру, цель - сокращение dbtime и нагрузки на IO указанного запроса, в table1 триллион записей и предикат "CAID = 111111" низкоселективен, то идея организации двойного прохода по table1 покажется слегка неумной.
3. Ваш вариант union all не эквиваленте исходному запросу.
4. Когда сделаете эквивалентным - рассмотрите случай CAID=DAID=111111

Можно перевести case expression из searched в simple - это несколько сократит издержки и упростит текст почти безотносительно к прочим факторам при условии, что соответствующие атрибуты TABLE2 not null - иначе simple форма становится неудобочитаемой.

Остальное - только "по месту".
К примеру, на решение повлияет возможность ситуации CAID=DAID=111111, соотношение мощностей DAID=111111 и (CAID=111111 and DAID<>111111), наличие индексов, доступный объем памяти и т.д.

Dshedoo4. Он рассмотрен.

Остальное из разряда "трава зелёная, а небо голубое".
4.1 DAID = null, CAID = 111111

"остальное" - печальная правда жизни.
Нельзя оптимизировать сферического коня по неопределенному критерию, любое конкретное предложение будет встречено контраргументом.