Что лучше, фильтрация результатов в БД или в приложении?

ну, самый точный ответ - в базе данных, но вы можете рассмотреть что-то вроде Linq2Sql, я имею в виду написать выражение на уровне представления, и оно будет проанализировано как оператор Sql на уровне доступа к данным.

конечно, есть некоторые ситуации, когда BLL должен получить некоторые данные от DAL, обработать их и затем вернуть в DAL. Возьмем пример: процедура PutOrder(Order value), которая должна проверить наличие заказанного товара.

public void PutOrder(Order _order)
{
foreach (OrderDetail _orderDetail in _order.Details)
   {
    int count = dalOrder.GetProductCount(_orderDetail.Product.ProductID);
    if (count == 0)
    throw new Exception (string.Format("Product {0} is not available",_orderDetail.Product.Name));
    }
    dalOrder.PutOrder(_order);
}

но если вы создаете представление «Обзор», не рекомендуется (с точки зрения производительности) получать все данные из Dal, а затем выбирать, что отображать в представлении «Обзор».

может быть поможет следующее:

public List<Product> SearchProduts(Criteria _criteria)
{
string sql = Parser.Parse(_criteria);
///code to pass the sql statement to Database procedure and get the corresponding data.
}

На уровне базы данных.

Базы данных должны быть оптимизированы для запросов, так зачем прикладывать все усилия, чтобы вернуть большой набор данных, а затем выполнять фильтрацию в своем приложении?

Общее правило: все, что разумно относится к обязанностям базы данных и может выполняться в вашей базе данных, делайте это в своей базе данных.

в базе данных.

Чтобы выделить другую точку зрения, это также действительно зависит от вашей модели абстракции данных, если у вас есть большой кеш 2-го уровня, который находится поверх вашей базы данных, и большая часть (или все) ваши данные, которые вы будете фильтровать, находятся в cache тогда да, оставайтесь внутри приложения и используйте кешированные данные.

Разница не очень важна, если рассматривать таблицы, которые никогда не будут содержать более нескольких десятков строк.

Фильтрация в БД становится очевидным выбором, когда вы рассматриваете таблицы, которые вырастут до тысяч, сотен тысяч или миллионов строк. Нет никакого смысла передавать такой объем данных для фильтрации подмножества записей.

Меня постоянно учили, что данные должны обрабатываться на уровне данных, когда это возможно. Фильтрация данных — это то, для чего специально предназначена БД и для чего она оптимизирована. Поэтому именно там это должно произойти.

Это также предотвращает дублирование усилий. Если фильтрация данных происходит на уровне данных, то другой код/системы могут извлечь выгоду из одной и той же хранимой процедуры вместо дублирования работы в вашем BLL.

Я обнаружил, что людям нравится помещать основную логику в раздел, в котором им наиболее удобно работать. Независимо от сильных сторон разработчика обработка данных должна по возможности выполняться на уровне данных.

Я задал аналогичный вопрос в классе SSRS ранее в этом году, когда хотел узнать «лучшую практику» для того, чтобы хранимая процедура извлекала запрошенные данные вместо выполнения TSQL в наборе данных отчета. Ответ, который я получил, был следующим: «Позвольте ядру базы данных делать «тяжелую работу». То есть выполнять весь выбор, группировку и сортировку в хранимой процедуре и позволить SSRS сконцентрироваться на доставке результатов.

То же самое относится и к вашему сценарию. Во что бы то ни стало, я бы проголосовал за всю фильтрацию в вашей хранимой процедуре. Вызовите sproc из своего приложения и позвольте базе данных сделать всю работу.

Если вы фильтруете в базе данных, то только те данные, которые требуются приложению, фактически отправляются по проводу между базой данных и сервером приложений. По этой причине я предлагаю фильтровать по базе данных.