Для примера, который вы привели, мне не ясно, как
SELECT * FROM TBL
WHERE YEAR(DATE) = 2001
GROUP BY COL1
HAVING COL2 NOT IN ID_LIST
отличается от
SELECT * FROM TBL
WHERE YEAR(DATE) = 2001
AND COL2 NOT IN ID_LIST
GROUP BY COL1
Следовательно, предложение Рохита о применении фильтра является эффективным решением.
HAVING
в основном работает так же, как и WHERE
, но после агрегирования с добавленной функцией вы можете использовать агрегаторы в предложении HAVING
. См. это обсуждение . Но в этом случае вы не применяете агрегаторы в предложении HAVING
, поэтому вы можете свободно использовать предложение WHERE
.
Относительно вложенных SQL-запросов, которые создает dbplyr. Это может показаться нелогичным, учитывая обычный акцент на чистый, понятный человеку код, но для автоматически генерируемых запросов dbplyr я рекомендую не беспокоиться о качестве сгенерированного компьютером кода. Он написан машиной, и (в основном) читается машиной, поэтому его удобочитаемость для человека менее важна.
Эффективность может быть проблемой со многими уровнями вложенности. Однако в 2017-06-09 dbplyr был предоставлен базовый оптимизатор SQL. Я не нашел (хотя я не тестировал всесторонне) вложенные автоматически сгенерированные запросы для выполнения значительно хуже, чем не вложенные пользовательские запросы. Но если производительность критична, вы, вероятно, захотите построить свой SQL-запрос вручную, набрав paste
текстовых строк в R.
Еще одна заключительная мысль - длина ID_LIST
также важна для рассмотрения. Это обсуждается в этом вопросе.