Эффективный пользовательский пейджинг в ASP.NET 2.0 при сортировке - PullRequest
Новая
       50

Эффективный пользовательский пейджинг в ASP.NET 2.0 при сортировке

1 голос
/ 04 августа 2011

У меня есть веб-приложение в ASP.NET 2.0, в котором мне нужно сделать пейджинг.Мой метод доступа к данным - извлечь DataSet из вызова базы данных, затем преобразовать его в List<Foo> (где Foo - мой тип, который я извлекаю из БД) и привязать к нему свой GridView.Моя причина в том, что я не хотел использовать строковые индексаторы в DataTables на всем протяжении моего приложения, и что я мог отделить логику отображения от базы данных, реализовав логику отображения в качестве свойств в моих классах.Это также означает, что я делаю сортировку в .NET вместо SQL.

Чтобы реализовать разбиение на страницы, мне нужно вытащить все Foo из базы данных, отсортировать список, а затем взять то, что я хочуиз полного списка для отображения: 

List<Foo> myFoo = MyDB.GetFoos();
myFoo.Sort(new Foo.FooComparer());
List<Foo> toDisplay = new List<Foo>();
for (int i = pageIndex * pageSize; i < (pageIndex + 1) * pageSize && i < myFoo.Count; i++)
{
  toDisplay.Add(myFoo[i]);
}
//bind grid

При достаточном количестве элементов это становится источником задержки;на моем компьютере разработчика, подключающемся к тестовой базе данных, при извлечении 5000 записей из БД для привязки одной сетки на экране требуется почти 0,5 секунды.

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

Кроме того, Linq to SQL решает эту проблему?Если я сортирую по пользовательскому свойству, реализованному в моем классе .NET, а затем использую .Skip(pageIndex * pageSize).Take(pageSize), он преобразует это в SQL, как отмечено в этот вопрос ?

Ответы [ 2 ]

0 голосов
/ 04 августа 2011

Linq to SQL будет использовать подход Row_Number, как описано в статье, и в целом он будет иметь эффективные пейджинговые запросы к базе данных.

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

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

Скажем так, вы хотите разместить запрос на этом: 

Select column1, column2, column3 from table1 where column1 > 100

Теперь допустим, что возвращается 1 000 000 строк. SQL Server по-прежнему должен выполнять свою процедуру подкачки более миллиона строк. Это займет несколько секунд, чтобы вывести на экран результирующий набор исходного запроса. И он должен делать это для каждого запроса.

Чтобы обеспечить поддержание производительности, необходимо ограничить количество возвращаемых записей, которые SQL будет отображать. 

Select TOP 10000 column1, column2, column3 from table1 where column1 > 100

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

0 голосов
/ 04 августа 2011

Да - я бы порекомендовал вам перенести выбор записей в SQL (сортировка и разбиение по страницам) - классический способ выполнения разбиения по страницам в SQL - использовать CTE. Я найду вам хороший пример и обновлю свой ответ. Здесь есть хороший пример http://softscenario.blogspot.com/2007/11/sql-2005-server-side-paging-using-cte.html - я гуглил "sql paging cte".

...