dev.net.ua

Курсоры - это самая плохая практика для базы данных. Т.к. они есть не привычное для нее поведение, что приводит к черезмерной загрузке базы данных (лишние чтения, блокировки и т.д.).

Для SQL Server 2005  и выше есть более элегантное решение.

SELECT * FROM

(

 SELECT *,

  row_number() over(order by <нужное поле для сортировки>) as num

 FROM MyTable

)

WHERE NUM  between <начало страницы> and <конец страницы>

Можно еще оптимизироваться заменив between на одно сравнение на "больше" и TOP.

PS. Также стоит посмотреть как ведет себя комплект из LinqDataSource и DataPager в .NET 3.5

PPS. Буду рад увидеть сравнение разницы во времени предлеженного и моего варианта, а Ваших объемах данных

Стандартний DataGrid - нічого не робить, робить SqlDataSource.

ІМХО, що перший, що другий приклад це крейзерство.

1) DataGrid - так вибачай, я мав на увазі GridView;

2) Незрозумів;

3) Пошук - http://search.live.com/results.aspx?srch=105&FORM=IE7RE&q=Paging+SQL+2005, усі перші сторінки розповідають про констукцію з WITH.

Чому я написав про крейзерство:

1) Рішення зі створенням додаткових таблиць це може бути і секуріті діркою, і занадто складним для підтримки.

2) Рішення з курсорами, просто занадто складним, також цікаво порівняти зі старндарними рішеннями за швидкістю та ресурсами.

Я зараз пробую встановити SQL 2008 November CTP - покищо нічого не вдається.

Упс, вибач, недочитав про тимчасовість таблиці. Тоді мабуть все ок, але цікавить питання якщо вже створили талицю, то навіщо там видяляти рядки, адже можна просто зробити колонку з індексом рядка, а потім витягати за допомогою BETWEEN/

> Результатом роботи алгоритму на курсорах стали 3860 мілісекунд, для row_number() - 27640 :(

Будь ласка, опублікуйте скрипти тестування (створення, наповнення таблиць та запити), є підозра щодо оптимальності скриптів з row_number() :)

Упс я пропустив AS T після вкладеного запиту без нього не працує.

Ось правильний синтаксис (використовув стандатну базу AdventureWorks):

select *

FROM

(

select *

, row_number() over(Order by SalesOrderID ) as num

from Sales.SalesOrderDetail

) as T

where num between 100000 and 100020

Сделал полную проверку на 1млн. записей. У меня SQL Server 2005 Developer Edition

Скрипт ниже:

create database paging

go

use paging

go

--Создаем таблицу

create table Profile

(

id int identity primary key,

LoginName nvarchar(100),

EMail nvarchar(100),

)

go

--Наполняем ее милионом записей всякого мусора

declare @i int

set @i = 0

while @i<1000000

begin

insert into Profile values(newid(), newid())

set @i=@i+1

end

--Вариант на row_number()

select getdate()

select * from

(

select *

, row_number() over(order by id) as num

from Profile

) as T

where num between 100000 and 100020

select getdate()

--Вариант на курсорах

select getdate()

declare @temp table(id int)

DECLARE temp_cursor SCROLL CURSOR FOR    

       select [ID]    

       from [Profile]

   declare @counter int

   declare @id   int

   OPEN temp_cursor          

   FETCH NEXT FROM temp_cursor    

   into @id            

   set @counter = 0      

   WHILE @@FETCH_STATUS = 0 AND @counter < 20

   BEGIN      

       insert into @temp ( [id] ) values ( @id )          

       set @counter = @counter + 1              

       FETCH NEXT FROM temp_cursor      

       into @id    

   END        

   CLOSE temp_cursor    

   DEALLOCATE temp_cursor      

   select    mp.[ID],      

               mp.[LoginName]

   from [Profile] as mp    

   where mp.[ID] in ( select [id] from @temp )

select getdate()

Для row_number() около 80 милисекунд, для курсора 5500.

ЗЫ. Фича моего метода проявляется только с вложеным запросом. С временной таблицей, это плохой вариант