페이징 쿼리는 자주 발생하는 문제입니다. 먼저 페이징 쿼리가 존재하는 이유를 살펴보겠습니다.
사용자 편의성: 사용자가 모든 데이터를 한 번에 볼 수 없으므로 페이지 단위로 탐색하는 것이 좋습니다.
성능 향상: 데이터베이스에서 모든 데이터를 한 번에 가져오는 속도가 느려집니다.
이제 위의 이유를 반박해 보겠습니다.
정말 편리한가요? 데이터가 20개뿐이라면 다음과 같은 상황을 고려합니다.
데이터가 1000개 항목을 초과하는 경우.
첫 번째 유형은 분명히 페이징 쿼리가 필요하지 않습니다. 이상한 점은 사용자가 페이지를 끝까지 넘길 의향이 없기 때문에 두 번째는 필요하지 않다는 것입니다. 사용자가 쿼리하는 데이터가 관심 있는 데이터 범위를 초과하는 경우 다시 입력하도록 허용해야 한다고 생각합니다. 쿼리 조건은 우리와 마찬가지로 Google을 사용하는 것과 동일합니다.
그러나 친숙한 애플리케이션 인터페이스로서 우리는 항상 사용자가 쿼리 결과를 완전히 이해할 수 있기를 바랍니다. 따라서 사용자에게 "얼마나 많은 데이터를 찾았습니까? 그러나 현재는 처음 1,000개의 항목만 표시할 수 있습니다. 모든 데이터를 보고 싶다면 어떻게 해야 할까요..."
성능이 좋아질까요?
데이터의 양이 적다면 당연히 성능이 크게 향상되지 않고 오히려 성능이 크게 저하됩니다. 데이터베이스가 불필요한 쿼리와 쿼리 조건을 수행하기 때문입니다.
데이터의 양이 많으면 항상 추가 카운트 쿼리를 실행해야 하기 때문에 성능이 크게 향상되지 않을 수 있으며, SQL을 결합할 경우 전체 테이블 스캔이 발생할 가능성이 매우 높습니다. 물론 이는 데이터베이스의 구현 원리에 따라 다릅니다.
페이징 쿼리가 성능에 미치는 영향과 데이터 양 사이의 관계는 곡선이어야 한다고 상상할 수 있습니다. 데이터 양이 적으면 성능이 저하되고, 데이터 양이 많으면 성능이 저하됩니다. (다른 데이터베이스에 따라) 개선될 수 있습니다. 테스트를 통해 곡선의 변곡점을 찾는 것이 핵심이다. 성능은 경험과 느낌으로 얻어지는 게 아니라, 테스트를 통해서 얻어지는 게 아니라, 데이터를 한꺼번에 다 꺼내면 확실히 공간 성능에 영향을 주게 되거든요. 그런데 지금은 메모리가 너무 저렴해요.
부정적인 영향 잘 설계된 웹 애플리케이션의 경우 다양한 클래스 간에 pageNo 및 PageSize를 전달하는 것이 정말 불편합니다. 이 두 데이터는 분명히 프레젠테이션 계층에 속합니다. 물론 RoR을 사용한다면 언급하지 않았습니다.
특히 데이터베이스 독립성을 고려할 때 프로그래밍 복잡성이 크게 증가합니다.
이상한 현상: 대규모 데이터베이스가 페이징 쿼리를 직접 제공하지 않는 이유는 무엇입니까? Oracle의 RowNo는 페이징에 사용되지 않으며 SQLServer의 Top도 사용되지 않습니다.
결론적으로
ExtremeTable, DisplayTag 및 JSF DataTable은 모두 간단한 페이징 방법, 즉 결과 컬렉션의 페이징을 제공합니다. 사용이 매우 편리하고 논리가 명확해 작업 효율성이 크게 향상됩니다. 대부분의 경우 이 방법을 직접 사용할 수 있습니다.
테스트를 통해 위 방법이 성능에 영향을 미치는 것으로 확인되면 페이징 쿼리 사용을 고려해 보세요.
사용자 수가 많은 애플리케이션의 경우 메모리 제약으로 인해 페이징 쿼리도 고려할 수 있습니다. 하지만 저는 개인적으로 같은 쿼리를 캐시에 넣는 캐싱 방식을 추천합니다...
개발자가 페이징 논리를 처리하지 못하도록 합리적인 디자인을 사용하십시오. 예를 들어 페이징 로직과 카운트 쿼리는 상위 클래스에 배치되고 개발자는 쿼리 조건을 결합하는 역할을 담당합니다. 구체적으로 디자인 패턴을 살펴보겠습니다.
누구나 토론을 환영합니다! ! !