One of the fastest-growing web database paging methods in theory

In the last article we talked about the database tradition of three kinds of paging methods and their pros and cons, and put forward a theoretical best pagination method, this article we will elaborate on this best paging method.
One: Idea.
When designing a Web database, if we want to compile every record, then only take the paging mode to make the Web database as soon as possible, rendering it to the end users, and not because of the 8-second principle of the user lost interest in browsing the page. But even with a paging approach, when there are multiple records of the database, it will inevitably make our users feel too slow to page. As I said in my last article, there are some flaws in the three pagination methods of almost every article. So, how do we get the database to fetch the records we need each time, this is a good implementation, and a cursor can return multiple recordsets, but it's hard to get the end of the database to consume a lot of resources just because it needs to retrieve a page of records. Finally, after my continuous rewriting program and test, I finally wrote the Web database paging method that I think is the fastest in theory.
Second: The specific implementation of the stored procedures.
We'll talk about this approach in conjunction with a BBS question. How to make a BBS every page only realistic need one page record? And what do we need to provide the database with those parameters? The following parameters may be available.
The first: is the number of pages we need today.
Second: The number of record sets for each page currently defined. This allows you to modify the number of records per page in the page program as needed. Of course, if you do not consider the scalability of the program, you can also directly in the database to specify that each page has n records.
Third: One output parameter: The number of total records in the current table is obtained from the database. (Note that he is not a record number of pages) he is equivalent to the RecordCount in the ADO paging method. If you don't need a total record number, you don't have to return him.
Let's look at the code for the specific stored procedure ...
CREATE PROCEDURE Dbo.pro_pageview
(
@tint_tableid Tinyint=1, this is the BBS's current layout ID, you can not care about him.
@int_pagenow int=0, @int_pagesize int=0,
@int_recordcount int=0 Output--is to get the total number of BBS a page.
)
As
SET NOCOUNT ON
DECLARE @int_allid int DECLARE @int_beginid int, @int_endid int
declare @int_pagebegin int, @int_pageend int

Select @int_allid =count (*) from Tab_discuss where tint_level=0 and tint_tableid= @tint_tableid
Select @int_recordcount = @int_allid--Gets the total number of tiles for the layout
DECLARE cro_fastread cursor Scroll
For the select int_id from Tab_discuss where tint_level=0 and tint_tableid= @tint_tableid ORDER BY int_id Desc--This defines cursor operations, but not pro Time record set, and cursors do not need to traverse all recordset.