Функция поиска только для чтения. Хранимые процедуры или IQueryable с POCO и Ef 4.0

Question

У нас есть некоторые функции поиска, которые могут возвращать десятки тысяч результатов из БД, хотя он будет только извлекать строки, необходимые для отображения, например, в. первые 10 записей. Когда запрашивается следующая страница, мы снова нажимаем на БД. Он выполняет поиск в нашей базе данных на основе набора переменных, и этот поиск затем может быть уточнен, что приведет к другому попаданию в базу данных. Запрос довольно сложный.

Мы искали разные способы сделать это в соответствии с нашей общей архитектурой.

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

Второй способ - использовать Linq to Entites или Entity SQL с Entity Framework 4.0, создавать запрос в коде на всем нашем концептуальном уровне и заполнять объекты POCO через IQueryable. Это имеет следующие преимущества:

• Абстракция : мы используем EF в других местах приложения, поэтому мы хотели бы поиск по абстрактной модели, если возможный.
• Тип безопасности и мы можем связать фильтры в IQueryable для чистого выполнения того, что мы хотим сделать, в объектно-ориентированном виде

Нашей главной заботой при таком подходе является производительность. Мы надеемся использовать Parrlel LINQ для организаций и можем использовать больше оборудования, если это необходимо. Небольшой удар по производительности подходит для более чистого шаблона разработки.

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

Answer 1

Я провел несколько тестов производительности и использую хранимую процедуру в EF4.0, заполняющую сущность или сложный тип, по производительности почти идентичную SP, доступ к которому осуществляется через ADO.NET, поэтому мы собираемся попробовать этот метод. Использование встроенных запросов EF было примерно в два раза медленнее, поэтому мы будем использовать SP в этой критической ситуации.

Answer 2

Вы сказали, что конечная цель - производительность. Это будет означать ADO.NET и прямой SQL для меня. Добавление EF поверх этого требует огромных затрат на то, что не требует отслеживания состояния, возможности обновления и даже не использует все результаты.

Напишите SQL для базы данных и позвольте ему выполнять разбиение на страницы как можно больше. Никогда не тяните тысячи записей, когда планируете их выбросить. Вы также не можете использовать преимущества своих серверов с EF для таких вещей, как FTS или оптимизация подсказок индекса. Вы находитесь во власти среды исполнения EF, которая является общей и не знает, как использовать преимущества конкретного оборудования или серверов.

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