2013-10-02 2 views
1

Добрый день,EF 5 большая стратегия загрузки данных

У меня есть следующие таблицы

РОДИТЕЛЕЙ 1 => N ДЕТИ 1 => N внуками.

Обе таблицы имеют более 30 столбцов.

Мне нужно выбрать более 50 000 записей из РОДИТЕЛЯ, плюс мне понадобятся определенные поля от ДЕТЕЙ и ГРАНДЖИЛЛЕ. Данные необходимы для управления в памяти (сложные алгоритмы на том, что было выбрано).

Я использую Entity Framework 5.

Я пробовал различные комбинации жадной загрузки (включая, проекция и т.д.), но я до сих пор не в состоянии сделать это лучше выполнить то perorms с LINQ к SQL в следующий сценарий:

" ВЫБРАТЬ из ПРОЕКТОВ

на связывании каждой строки: ВЫБРАТЬ от детей ВЫБРАТЬ из внуки

"

он генерирует не менее 50 001 вызовов в БД, но он по-прежнему работает лучше, чем любой из моих подходов к EF, которые занимают больше x5, чем текущий проект LINQ-to-SQL.

Лучшим решением было бы иметь запрос WHERE IN для детей, но он не доступен в EF 5 в собственной реализации (содержит не режет - слишком медленно для плохо сделанного ...).

Любые идеи будут высоко оценены.

Спасибо,

+1

Сетка, отображающая 50000 строк? –

+3

Согласен, никто не собирается просеивать через 50 000 строк, предоставленных им. Прежде чем показывать в пользовательском интерфейсе, вам нужно посмотреть на пейджинг и/или фильтрацию. – gunr2171

+0

Можете ли вы добавить хранимую процедуру или просмотреть базу данных и добавить ее в свою модель? –

ответ

1

Я предполагаю, что вы реализуете подкачки на ваш взгляд сетки и не кладя тысячи строк в табличном сразу. Если это так, вы можете выбрать только 10 или несколько строк, которые вы показываете в режиме сетки за раз. С этим будет намного легче работать.

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

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

+0

Спасибо, что разместили ссылку! –

0

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

Создание ViewModel с необходимыми полями:

public class MyViewModel 
{ 
    public string one {get; set;} 
    public string two {get; set;} 
} 

Затем в действии контроллера:

MyViewModel result = db.Database.SqlQuery<MyViewModel> 
        ("SELECT a.one, b.two" + 
        " FROM Table1 a, Table2 b" + 
        " WHERE a.id == somthing" 
        ).FirstOrDefault(); 
0

пейджинг не будет работать для I нужны данные для сортировки на основе вычисленного поля. Поле может быть рассчитано только в памяти веб-сервера, так как для расчета требуется информация о клиенте (да, да, есть способ передать эту информацию на сервер db, но это не вариант).

Решение: использование (вар onecontext = новый myCTx()) { ВЫБРАТЬ все из ПРОЕКТОВ и осуществлять Context.EntityName.SQLQuery() по всем внукам, используя старую добрый WHERE IN построить (я положил его все в частичные классы моих сущностей в качестве расширений).

}

таким образом я получаю все мои данные в N дб поездок, где N ì число поколений, которое отлично. Затем контекст EF соединяет все вместе. И затем я выполняю все свои r

EF 6 должен иметь WHERE IN встроенный, поэтому я предполагаю, что этот подход станет более очевидным тогда. Имейте в виду: использование Contains() не является опцией для больших данных, поскольку для него производится несколько OR вместо прямого IN. Да, ADO.NET затем переводит OR в IN, но до этого происходит действительно тяжелый подъем, который убивает ваш сервер приложений.

Смежные вопросы