foxty [원작]은
최근 high-small 페이징 알고리즘을 작성하는 방법을 연구하고 있으며 이를 정리했으며 아이디어는 다음과 같습니다.
먼저, 데이터베이스에 자동 번호 매기기 필드(ID)가 있어야 합니다. 그런 다음 첫 번째 방문에서 모든 레코드를 꺼내고 각 페이지의 레코드 수를 PageSize로 맞춤화하고 페이지 수를 계산한 다음 페이지 수(0)를 기준으로 1차원 배열 PageId(PageCount)를 만듭니다. )는 레코드의 초기 테스트 조건을 저장한 후 각 요소에 해당하는 각 페이지에 해당하는 ID 경계 코드를 저장합니다(
1. ID 경계 코드: 데이터베이스 레코드 ID 레코드 순서가 다음과 같은 경우: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
ID별로 정렬해야 한다고 가정하면 PageSize = 5, Pagecount = 4, PageId(4)
PageId 배열의 값은 PageId(0) = 1, PageId(1) = 5, PageId(2) = 10, PageId(3) = 15, PageId(4) = 16 입니다.
i번째 페이지에 접근할 때 [PageId(i-1), PageId(i)) 사이의 레코드를 직접 검색하면 매번 PageSize 레코드만 검색됩니다.
ID를 기준으로 역순으로 정렬해야 한다고 가정해 보겠습니다.
PageId 배열의 값은 PageId(0) = 16, PageId(1) = 12, PageId(2) = 7, PageId(3) = 2, PageId(4) = 1이다. i번째에 접근할 때 페이지에서 [ PageId(i-1) , PageId(i) )
)
에 속한 ID를 직접 찾아보세요.
쉽게 액세스할 수 있도록 PageId() 배열을 Application()에 저장하여 호출기에 처음 액세스할 때만 Application()이 초기화되도록 합니다. 코드 부분은 다음과 같습니다. (이하 새 프로그램이라고 함)
<%
시간1 = 타이머()
딤 콘
Conn = Server.CreateObject("Adodb.Connection") 설정
Conn.open "드라이버={MicroSoft 액세스 드라이버(*.mdb)};Dbq="&Server.MapPath("db.mdb")
'www.downcodes.com
희미한 페이지, 페이지 수, 페이지 ID, 페이지 목록
희미한 Rs, SQL
희미한 IsInit,i
IsInit = False '플래그는 애플리케이션("PageId")이 초기화되는지 여부를 결정하는 데 사용됩니다.
PageList = 20 '각 페이지에 표시할 데이터를 20개로 설정
Rs = Server.CreateObject("Adodb.Recordset") 설정
Page = Request.QueryString("Page") '페이지 번호의 유형을 확인해야 합니다.
If IsEmpty(Application("PageId")) Then 'Application("PageId")이 아직 초기화되지 않은 경우 먼저 초기화합니다.
Response.Write("앱 초기화!<br>")
Sql = "Select * From test Order By Id Desc" 'ID를 기준으로 역순으로 정렬된다고 가정합니다.
Rs.open Sql,Conn,1,1 '레코드세트 개체를 가져옵니다.
그렇지 않은 경우(Rs.Eof 또는 Rs.Bof)
Rs.PageSize = PageList '페이지당 레코드 수를 설정합니다.
페이지카운트 = Rs.페이지카운트
ReDim PageId(PageCounts) ' PageId 배열 재정의
For i = 0 To PageCounts '배열 PageId()에 값 할당 시작
Rs.eof인 경우 종료 대상
PageId(i) = Rs("ID")
Rs.이동(페이지 목록)
다음
Rs.MoveLast
PageId(페이지카운트) = Rs("ID")
응용프로그램.잠금()
Application("PageId") = 페이지 ID
응용 프로그램.잠금 해제()
종료 조건
Rs.Close
종료 조건
IdStart = Clng(Application("PageId")(페이지-1))
IdEnd = Clng(Application("PageId")(페이지))
Sql = "id<="&IdStart&" 및 id>"&IdEnd&" 테스트에서 *를 선택하세요. "
Rs.open SQL,Conn,1,1
Rs.eof가 아닌 동안
응답.쓰기(rs(0)&"--"&rs(1))
Rs.MoveNext
향하게 하다
Rs.Close
Rs = 없음으로 설정
연결 닫기
SetConn=아무것도 없음
i = 1 To Ubound(Application("PageId"))
Response.Write("<a href='Test1.asp?Page="&i&"'>"&i&"</a> ")
다음
시간2 = 타이머()
Response.Write("<br>"&(Time2-Time1)*1000)
'Application.Contents.Remove("페이지Id")
%>
기존 페이징 코드는 다음과 같습니다. (이하 기존 프로그램이라 함)
<%
시간1 = 타이머()
딤 콘
Conn = Server.CreateObject("Adodb.Connection") 설정
Conn.open "드라이버={MicroSoft 액세스 드라이버(*.mdb)};Dbq="&Server.MapPath("db.mdb")
희미한 페이지, 페이지 수, 페이지 목록
희미한 Rs, SQL
페이지리스트 = 20
페이지 = Request.QueryString( "페이지" )
Rs = Server.CreateObject("Adodb.Recordset") 설정
Sql = "ID 설명별로 테스트 순서에서 *를 선택하세요."
Rs.Open SQL, Conn,1,1
페이지 = ""이면 페이지 = 1
그렇지 않은 경우( Rs.eof 또는 Rs.Bof ) 그러면
Rs.PageSize = 페이지 목록
페이지카운트 = Rs.페이지카운트
Rs.AbsolutePage = 페이지
종료 조건
i = 1에서 PageList로
Rs.eof인 경우 종료 대상
응답.쓰기(Rs(0)&"------"&Rs(1)&"<br>")
Rs.MoveNext
다음
i = 1의 경우 페이지 수
Response.Write("<a href='Test.asp?Page="&i&"'>"&i&"</a> ")
다음
시간2 = 타이머()
Response.Write("<br>"&(Time2-Time1)*1000)
%>
실제로 전반적인 아이디어는 Application("PageId")의 전역 배열을 생성하는 것이며 각 요소는 페이지의 레코드 ID 범위를 저장합니다. 예를 들어 Application("PageId")(0)은 다음의 ID를 저장합니다. 그런 다음 Application("PageId")(1)은 다음 페이지의 첫 번째 ID를 저장합니다. i번째 페이지에 액세스해야 하는 경우 [Application( "PageId")(i- 1) , Application("i") ) 이렇게 하면 매번 모든 레코드를 검색하는 것이 아니라 필요한 개수만큼만 검색하면 됩니다. 첫 번째 액세스 Application("PageId") 배열을 생성해야 할 때 N번째(N>1) 액세스할 때 속도가 거의 10배 빨라집니다. 시험:
1. 데이터베이스에는 32,000개의 레코드가 있습니다. 이전 프로그램은 한 페이지에 액세스하는 데 약 500밀리초가 걸렸습니다. 새 프로그램은 첫 번째 액세스 중에만 이 시간에 도달하고 그 이후에는 매번 약 55밀리초만 걸립니다.
2. 데이터를 64,000개 레코드로 늘립니다. 이전 프로그램은 한 페이지에 액세스하는 데 약 1,000밀리초가 걸립니다. 새 프로그램도 처음 액세스할 때마다 이 수준에 도달합니다.
3. 데이터를 128,000개 레코드로 늘립니다. 이전 프로그램은 한 페이지에 액세스하는 데 약 1900밀리초가 걸리고, 새 프로그램은 처음으로 한 페이지에 액세스하는 데 약 2300밀리초가 걸리며, 각 액세스에는 약 70밀리초만 걸립니다.
여기서 주목해야 할 점은 데이터베이스가 수정될 때마다 Application("PageId")을 다시 할당해야 한다는 것입니다.
연구 경험: (우선 경험에 대해 Ye Zi(DVBBS)에게 감사드립니다.) 내장된 페이징 프로그램인 Rs.RecordCount는 리소스를 많이 소모합니다. 결과적으로 Rs.PageCount...도 리소스를 소비하는 것으로 추정되며 Rs.GetRows()를 사용하는 효과도 크게 향상됩니다.
비교해 보면 리프 알고리즘의 속도와 효율성은 레코드가 상대적으로 높을 때 상대적으로 높습니다. 그러나 그다지 안정적이지는 않으며 때로는 (드물게) 약 30ms에서 1-200ms로 점프합니다. 그 이후에는 효율성이 50~80밀리초로 크게 떨어지며, 나중에 효율성이 낮아집니다. 새로운 알고리즘의 효율성은 처음에는 약 500밀리초로 상대적으로 낮지만 이후에는 일반적으로 약 50밀리초이며 라이브러리의 레코드 수가 변경됨에 따라 이 속도는 동일하게 유지됩니다. 아무것도 변하지 않을 것입니다. 다음에는 Ye Ye와 내 알고리즘을 결합해 보려고 하는데 Ye Ye의 알고리즘은 정말 훌륭하고 다재다능합니다. 채팅에만 사용할 수 있어요.