Выбор того, извлекать ли большее количество объектов и затем фильтровать или просто извлекать правильные объекты, в первую очередь зависит от базовых данных. Большинство приложений будет использовать комбинацию из двух.
Вещи, которые я бы рассмотрел:
Пропускная способность сети и требования к памяти
Если после фильтрации имеется небольшое количество результатов, но значительно большее количество результатов до фильтрации, то фильтрация в коде может быть пустой тратой пропускной способности и ресурсов памяти.
Скорость запроса
Фильтрация результатов в базе данных может быть более дорогой, чем логика кода - диск или память. Индексы необходимы, чтобы это стоило.
ремонтопригодность
Создание новых запросов может занимать много времени. Это определенно будет означать написание некоторого sql и пересмотр различных этапов тестирования. Может потребоваться изменение схемы БД, например, добавление индекса для ускорения запроса.
При решении этой проблемы в Java, возможно, стоит рассмотреть шаблон посетителя. Я часто использую два интерфейса: SingleMatcher и MultipleMatcher для фильтрации коллекции объектов. Их реализация может быть объединена для создания новых пользовательских критериев. Еще одним преимуществом этого является то, что если у вас есть подходящие пользователи, вам не нужно возвращаться к тестированию для создания новых критериев.