ABOUT ME

-

오늘
-
어제
-
-
  • KOSTA 교육 61일차(Spring, Oracle DB Hint, Paging, Search)
    Review 2020. 6. 24. 01:08

    19. 1. 31(목)

     

    배운 내용

     

    1. Oracle DB Hint
    2. Paging
    3. Search

    1. Oracle DB Hint

    SELECT문을 전달할 때 ‘힌트(Hint)’라는 것을 사용하여 개발자가 실행 조건을 걸어주는 것을 말한다.

    • 힌트 구문에서 에러가 나도 전혀 SQL 실행에 지장을 주지 않는다.
    • 개발자가 원하는 대로 SQL이 실행 되는지 확인하는 습관이 필요하다.
    • Order by의 FullScan하는 단점을 극복할 수 있다.
    • INDEX_ASC or DESC (테이블명 PK)를 사용하여 정렬을 생략한다.
    • FULL(테이블명)으로 FullScannig도 가능하다.

     

    order by 예제

    • order by 정렬은 데이터가 많은 경우 엄청난 성능의 저하를 가져오기 때문에 데이터가 적거나, 정렬을 빠르게 하는 방법이 있지 않으면 지양한다.
    • 계획 설명에서 보듯이 테이블을 FULL로 scan 한 것을 볼 수 있다.

     

    Hint(INDEX 사용) 예제

    • /* + INDEX_ASC(tbl_board(테이블명) pk_board(제약조건 명))*/
      * FROM tbl_board(테이블명) WHERE bno > 0(조건);
    • Hint를 사용하여 자동으로 정렬된 결과이다.

     

    • order by를 사용했을 때와는 다르게 SORT를 하지 않았고 제약조건을 사용하여 Range Scan을 했다는 점이다.
    • 적은 데이터지만 걸린 시간도 단축된 것을 볼 수 있다.
    • 여기서 가장 중요한 개념은 ‘정렬이 되어 있다는 점'이다.

     

    ROWNUM 예제
    • SQL이 실행된 결과에 넘버링을 해주는 역할을 한다.
    • 모든 SELECT문에 사용 가능하다.

     

    • ROWNUM을 선언하여 나오는 결과의 순서를 매길 수 있다.
    • 테이블에 존재하는 것이 아니라 가져온 데이터를 이용하여 번호를 매긴다.
    • 위의 문제는 FullScan을 하면서 정렬이 되지 않았을 때 ROWNUM을 매기고 차후에 정렬이 되기 때문에 뒤죽박죽 상태란 것을 알 수 있다.

     

    • 하지만 위와 달리 Hint에 INDEX를 사용하여 기본 정렬 상태에서 ROWNUM을 매긴다면 순서에 맞게 매겨진 것을 확인 할 수 있다.
    • 실행 계획에도 FULL이 아닌 것을 확인 할 수 있다.

     

    인라인뷰(in-line view) 예시
    • 페이징을 처리하기 위해서 인라인뷰로 처리해야만 문제가 없다.
    • SELECT문 FROM절에 다시 SELECT문을 이용하여 나타낸다.

     

    • 위와 같이 ROWNUM이 높은 순서대로 출력된 것을 볼 수 있다.
    • 이 때 2페이지부분을 구하기 위해 다시 코드를 작성한다.

     

    • 하지만 아무 것도 나오지 않는 것을 알 수 있다.
    • 이유는 ROWNUM은 새로운 데이터를 가져오는 순간 1로 시작되어 어떠한 조건이 1보다 클 등 만족을 못하면 결과가 없게 된다.

     

    • 위와 같이 FROM( SELECT)를 이용하여 SELECT문에는 ROWNUM의 총 갯수를 정해주고 정한 rn의 조건을 주면 조건에 해당되는 데이터가 출력된다.

    2. Paging

    MyBatis와 Spring에서의 페이징 처리이다.

     

    Mapper Test

    • 페이징 처리를 위해선 페이지 번호, 한 페이지의 글 갯수를 나타내 줘야 하기 때문에 객체를 생성한다.
    • 생성자를 생성하여 각각의 파라미터 값을 선언한다.

     

    • 해당 도메인 객체를 가지는 메소드를 선언한다.
    • VO객체를 사용하기 위해서 List로 담아 선언한다.

     

    • 인라인뷰를 사용한 쿼리문을 작성한다.

     

    • 1페이지에 해당되는 2개의 글을 나타내는 테스트를 진행한다.

     

    • 두개의 글이 출력되는 것을 확인할 수 있다.

     

    Service Test

    • 파라미터로 처리하도록 Criteria 객체를 파라미터에 선언한다.

     

    • 매핑한 페이징처리 메소드를 return한다.

     

    • service에서 정의한 getList 메소드를 호출하여 출력한다.

     

    • 정상적으로 출력이 된다.

     

    Controller Test

    • 페이징 처리 된 list를 불러줘야한다.
    • model객체로 페이징 처리된 메소드를 담고 가져간다.

     

    • get방식으로 list까지 가져간다.
    • 파라미터 값으로 PageNum은 1, amount는 2를 가져간다.

     

    • 위와 같이 출력된다.

     

    Paging 처리
    • Paging 처리를 위해서 도메인 객체를 생성한다.

     

    • PageDTO에 기존에 만들었던 객체인 Criteria를 선언하여 페이지 관련된 값을 넘겨받고, total을 선언하여 총 데이터 수를 입력한다.
    • 그리고 PageDTO를 생성하고 파라미터 값을 넣어주면 연산이 가능하게끔 로직을 작성한다.

     

    • list에 Criteria 객체를 생성하고 Model객체를 생성하여 데이터를 담는다.
    • service객체의 출력메소드를 list를 담는다.
    • PageDTO를 선언하여 파라미터 값에 값을 선언하고 pageMaker에 담는다.

     

    • Model 객체로 보내준 pageMaker를 el태그롤 통해 페이지 뷰를 작성한다.
    • a태그를 사용하여 href에 이전, 현재, 다음 페이지의 el태그를 선언한다.

     

    • 페이지를 누르면 넘어가는 Form태그이다.

     

    • a태그 버튼을 누르면 pageNum인 href를 넣고 submit하여 이동하는 스크립트를 작성한다.

     

    • 밑에 페이징 처리가 된 것을 볼 수 있다.

     

    상세 보기(조회)

    • move라는 class를 주고 bno를 가져간다.
    • 현재 Criteria는 보이지 않지만 다른 부분에서 가져온다.(만약 이 상황이 아니라면 가져가야 한다는 것을 인지)

     

    • click 이벤트를 주어 input태그를 생성해주고 submit한다.

     

    • 게시글을 클릭했을 때 가져가는 값

     

    목록페이지 재이동

    • 위 결과에서 제목을 클릭하고 다시 list로 돌아오면 목록페이지의 Criteria 객체를 가져오지 못해 처음 페이지로 돌아가게 된다.
    • 그래서 cri의 값을 가지고 가기 위해 cri를 선언해준다.

     

    • input태그에 가져갈 값을 선언한다.

     

    • list를 클릭해도 이상없이 기존 페이지로 돌아온다.

     

    수정 / 삭제

    • view에서 Controller에서 보낸 값을 받기 위해 hidden으로 받는다.

     

    • redirect로 보내기 위하여 객체를 생성하고 pageNum, amount를 cri객체에 있는 값을 담아 전달한다.

     

    • 수정 및 삭제에서의 페이지 이동 스크립트문이다.

     

    • 총 글 갯수를 구하기 위한 메소드

     

    • 글 갯수를 count로 실셈한다.

     

    • Mapping한 메소드를 return한다.

     

    • total에 service 메소드를 선언하고 PageDTO에 넣으면 DB에 저장되어 있는 데이터가 출력된다.

     

    • list에 DB의 데이터를 불러와서 나타낸다.

    3. Search

    SELECT문을 활용한 검색기능과 화면을 처리한다.

    • LIKE 처리를 통해 키워드를 사용한다.
    • 인라인뷰를 통해 쿼리문을 작성한다.

     

    • 페이징 처리에 검색 조건이 들어가면서 변화가 필요하다.
    • 변수 type, keyword가 추가되었다.
    • 삼항연산자를 사용하여 null이면 배열을 만들고 아니라면 split을 이용하여 각 타입을 분리시킨다.

     

    • 맨 앞에 온 OR은 지우고 괄호와 AND를 prefix와 suffix로 나타낸다.
    • Criteria 객체에서 생성한 TypeArr의 type을 반복한다.
    • choose when 구문으로 조건별 LIKE를 선언하여 키워드를 입력 시 OR을 이용하여 구문을 만든다.

     

    • 키워드와 타입을 선언하여 페이징을 forEach문을 통해 전체 출력 test를 한다.

     

    • 위와 함께 양호하게 출력 되는 것을 알 수 있다.

     

    • 쿼리문을 sql태그로 묶어 inclue태그로 해당 쿼리문을 동일하게 사용할 수 있다.
    • 위 방법은 중복되는 코드를 줄여주고 유지보수가 용이하다.

     

    • select option 태그를 사용하여 pageMaker의 cri객체의 type이 각 검색할 내용들이라면 selected 하고 아니면 공백을 둔다.
    • 그리고 keyword를 입력하는 input태그를 추가한다.

     

    • 자바스크립트를 이용하여 예외처리를 진행한다.

     

    • 예외처리 한 결과이다.

     

    • 검색 이후 페이지를 이동해도 동일한 검색 list가 출력되어야 하기 때문에 hidden으로 주어 type과 keyword를 선언한다.

     

    • 수정과 삭제 메소드에 redirect로 cri객체를 list로 보낸다.

     

    • UriComponentsBuilder를 사용하여 파라미터를 계속 유지 및 연결하여 URL의 형태로 만들어 준다.
    • Redirect를 하거나 form태그를 사용할 일이 많이 줄어든다.

     

    • 위처럼 UriComponentsBuilder를 이용하면 주석 처리한 부분의 코드가 사라지고 return만 해주면 된다.

     

    • Key로 검색한 결과 값이 출력된다.

    오늘 교육 간 느낀 점

    오늘 배운 주요 기능은 DB의 Hint활용, 페이징 처리, 검색 기능 세 가지를 학습했다. DB의 경우는 SQL 수업을 들었지만 설명해주지 않은 부분인데 이번 기회로 알게 되어서 활용도가 높을 것 같다.
    페이징 처리는 JSP에서도 어려웠지만 여기서도 어렵다. 코드 자체도 복잡하고 생각할 부분이 너무 많다.
    검색은 데이터가 움직이는 부분이 너무 많아서 헷갈리고 어렵다.

     

    오늘 전체적으로 일반 Spring, Java 코드 뿐만 아니라 JavaScript적인 부분이 많이 나와서 제대로 이해하지 못하였다. 스프링 자체만 보면 어노테이션을 활용하여 이해를 할 수 있는데 스크립트 적인 부분은 학습이 많이 부족해서인지 솔직히 보면서도 무슨 말인지 잘 모르겠다.

     

    백엔드로 가기 위해서 기본적인 CRUD는 물론이지만 결국 뷰로 데이터를 보내지 못하면 아무 것도 못하는 쓸모없는 기술인 것을 오늘 느꼈다. 꼭 시간내서 기본적인 스크립트문을 작성할 수 있도록 공부해야겠다.

    댓글