페이징 알고리즘은 웹 개발자들이 매우 우려하는 문제입니다. 거의 모든 데이터베이스 관련 애플리케이션에는 페이징 알고리즘이 포함되어 있습니다. 이 분야에 대해서는 논의할 내용이 없을 것 같지만 실제로는 변경해 보겠습니다. 데이터 표현을 변경함으로써 더 나은 페이징 알고리즘을 사용할 수 있는지 살펴보겠습니다.
먼저 기존의 몇 가지 방법에 대해 이야기해 보겠습니다.
하나는 DataGrid를 통한 페이징입니다. 이 방법은 가장 간단하지만 효율적이지 않으며 필요한 데이터 앞에 있는 모든 데이터를 읽어야 합니다.
두 번째는 시작 레코드와 레코드 번호를 DbDataAdapter.Fill로 지정하여 DataSet의 페이징 방법을 채우는 것입니다. 이 방법 역시 간단하지만, 필요한 데이터 앞에 있는 모든 데이터를 읽어야 한다는 점에서 비효율적입니다.
세 번째는 다중 선택 상단 및 다중 정렬을 통해 테이블 중앙에서 필요한 레코드를 선택하는 것입니다. 인접한 페이지의 데이터가 반복되는 것을 방지하려면 not in을 사용해야 합니다. 이로 인해 다음과 같은 꼬리 데이터가 발생합니다. 많은 양의 데이터가 포함된 테이블을 선택하면 데이터베이스 성능이 크게 저하됩니다.
실제로 전통적인 C/S 응용 프로그램에서 스크롤 막대를 사용한 그리드 표현을 예로 들어 테이블의 표시 형식을 변경한다고 가정해 보겠습니다. 실제로 이 방법은 데이터베이스 테이블에 가장 적합한 표시 방법이며 C/S 응용 프로그램에서 일반적으로 사용되는 표시 방법입니다. 웹 애플리케이션 1,2,3…의 페이지 번호 연결 방식이나 이전 페이지와 다음 페이지 버튼의 페이지 번호 브라우징 바 방식은 최후의 수단이다. 왜냐하면 웹 애플리케이션에서는 스크롤 바를 구현하는 데 간단한 기술을 사용할 수 없기 때문이다. 그리드.
데이터베이스의 테이블에는 모두 테이블의 서로 다른 레코드를 구별하기 위한 기본 키가 있습니다. 사용자 인터페이스의 그리드에 있는 데이터에도 논리적으로 기본 키가 있습니다. 그렇지 않으면 데이터가 모호해집니다. 그러나 대부분의 애플리케이션에서는 설정이 없습니다. 읽기 데이터의 기본 키를 아는 것은 불가능합니다. 몇몇 응용 프로그램이 이를 설정하더라도 읽기 데이터의 기본 키를 알고 있지만 실제로는 이를 페이징에 적용하지 않습니다. 읽은 데이터의 기본 키를 사용하면 매우 쉽게 페이징을 수행할 수 있습니다.
홈페이지의 알고리즘은 매우 간단합니다.
상단 페이지 크기 선택 * 테이블 이름에서 기본 키 순서
스크롤 막대가 있는 테이블의 경우 데이터가 페이지 단위로 순차적으로 스크롤됩니다. 스크롤 막대를 드래그하더라도 페이지 단위로 선택한 위치로 스크롤할 수 있습니다. 새 페이지의 알고리즘은 다음과 같습니다.
상위 페이지 크기 선택 * 기본 키 > 이전 페이지 끝에 기록된 기본 키가 있는 테이블 이름에서 기본 키순으로
정렬 캐싱을 사용하는 경우 모든 데이터는 한 번만 다운로드하면 되며 새 데이터는 스크롤할 때만 다운로드됩니다. 끝.
이 알고리즘을 사용하려면 그리드에 있는 데이터의 기본 키를 알아야 하며 기본 키 데이터를 페이징에 적용해야 합니다. 여러 기본 키와 정렬된 테이블의 경우 알고리즘은 동일하지만 명령문은 더 복잡합니다. 홈 페이지에서 시작할 수 있을 뿐만 아니라 마지막 페이지에서 시작하여 앞으로 스크롤할 수도 있습니다.
이 알고리즘의 성능에는 문제가 없습니다. 테이블이 아무리 커도 위치가 선택되는 레코드는 동일합니다. 홈 페이지, 이전 페이지, 다음 페이지 및 페이징 선택 방법을 사용하는 것이 더 적합합니다. 마지막 페이지이며 스크롤 막대에 더 적합합니다. 지정된 페이지 번호의 페이지 매김에는 적합하지 않습니다.
이 알고리즘을 사용하는 스크롤 막대가 있는 그리드에 대해서는 데모 www.BizStruct.cn을 참조하십시오.
질문을 제기할 때 먼저 두 가지 사항을 고려하십시오. 그렇지 않으면 이 알고리즘을 당사 시스템과 결합하는 이점을 깨닫지 못할 수도 있습니다.
첫째, 전통적인 C/S 신청서와 웹상의 페이징 양식 중 어느 것이 더 편리한가요?
첫째, 우리가 구현한 스크롤 막대가 있는 테이블은 기존 C/S 애플리케이션의 테이블과 얼마나 다른가요?
답변 설명:
일부 응답에서는 "xx페이지로 이동"과 같은 작업을 구현할 수 없다고 명시했습니다.
그런데 생각해 보면, C/S 응용 환경에서 누구나 이런 페이지 점프 방법을 사용한다면 모두가 이상하게 생각할 것이다.
우리가 구현한 스크롤 바가 있는 그리드는 LAN 환경에서 기존 C/S 애플리케이션과 거의 비슷하며, WAN 환경에서도 매우 빠릅니다.
웹 애플리케이션의 "XX 페이지로 이동 작업"은 실제로 최후의 수단입니다. 기존 C/S 애플리케이션의 그리드를 구현할 수 있다면 왜 이것을 사용해야 할까요?