Где тут две группировки-то? для обоих показателей группировка одна и та же - по уведомлению. Вот условия отбора - да, разные. Потому и применяется заново изобретённое Вами условное агрегирование.


Это не костыль, а правильное, в том числе идеологически, решение.

Есть только одно допущение - что UF_FLAG_READ содержит только значения 0 и 1. Если поле определено как UF_FLAG_READ TINYINT NOT NULL CHECK (UF_FLAG_READ IN (0,1)) , то решение правильное вообще со всех сторон, иначе вместо SUM(UF_FLAG_READ) AS "read" должно использоваться SUM(UF_FLAG_READ = 1) AS "read" (а в других СУБД - так и вообще SUM(CASE WHEN UF_FLAG_READ = 1 THEN 1 ELSE 0 END) AS "read" ).

Единственное сомнительное место, да и то с точки зрения производительности - это WHERE UF_NOTIFICATION IN {ids} . Если значений в списке больше десятка, сервер проигнорирует наличие индекса и устроит фуллскан, даже если селективность по условию высока. В этом случае формирование набора значений как набора строк (в СТЕ или временной таблице) может быть оправданным решением.