10장 객체지향 쿼리 언어 (1)

[MinJunKweon]

10.3 전까지

[LOG-INFO]

• SQL: DB 테이블 대상 데이터 중심의 쿼리
• JPQL: Entity 객체를 대상으로 하는 객체지향 쿼리
• JPA에서 제공하는 검색 방법
  • JPQL(Java persistence Query Lang.)
    • SQL을 추상화해서 특정 DB에 의존하지 않는다
    • SQL보다 간결하다
    • 문자열로 작성하기 때문에 오타/네이밍변경이 있으면 컴파일 타임에 체크하기 어렵고 런타입에 체크 가능
  • Criteria Query
    • JPQL을 생성하는 빌더 클래스
    • JPQL과 달리 문자열이 아닌 코드로 JPQL 작성 가능
      • 컴파일 타임에 오류 발견 가능
      • 동적 쿼리를 작성하기 편하다
      • 단, 필드명은 JPQL처럼 문자열로 작성하거나 Meta Model을 사용해야 한다
    • 장점이 많지만, 복잡하고 장황하며 직관적인지 않다
  • QueryDSL: JPQL을 편하게 작성하도록 도와주는 빌더 클래스 모음

    • 비표준 오픈소스 프레임워크였구나..?

    • 코드기반이라 컴파일타임 체크 가능하고, 단순하며 사용하기 쉽다 (Criteria나 JPQL 대비)
  • Native SQL
  • JDBC, SQL Mapper framework(e.g. MyBatis)
    • JPA와 같이 사용한다면, 적절한 시점에 flush를 해주어야 한다. 그렇지 않으면 데이터 무결성을 훼손할 수 있다
      • Spring Framework를 사용하면 JPA와 MyBatis 손쉽게 통합 가능
      • Spring Framework의 AOP를 활용해서 적절히 flush해줄 수도 있음
• p.363. JPQL에서 new 연산 사용하는 내용

  • 너무 더러워질 듯

  • 또, package나 class 명 변경 시 컴파일타임 체크 어려울 듯

  • 이런건 그냥 어플리케이션단에서 하자...

• p.366. Oracle 페이징 쿼리 ㅂㄷㅂㄷ.....

• 컬렉션식, 문자함수, 날짜함수, CASE문의 대부분은 그냥 어플리케이션에서 처리하는게 좋겠다...

  • 간단하더라도 DB에서의 로직 처리는 없어야 한다고 생각함

    • 최적화를 위해 사용할 수 있지 않을까?

      • 이런걸로 최적화를 찔끔찔끔 한다고 해서 성능이 크게 향상되는 경우는 보지 못 함. 오히려 유지보수성이 매우 안좋아짐.

        • 이정도의 최적화까지 필요하다면 다른 DB로 옮기거나(Cassandra, ES, HBase 등) 캐싱을 하거나 배치처리를 하는 등 다른 방법을 찾는 것이 좋을 듯

[MinJunKweon]

• JPQL
  • SQL을 추상화해서 특정 DB에 의존하지 않음
  • SQL 보다 간결함
• Criteria 쿼리
  • 프로그래밍 코드로 JPQL을 작성할 수 있음
  • 컴파일 시점에 오류를 발견하고, IDE 코드 자동완성도 가능
  • 동적 쿼리 작성 가능
• QueryDSL
  • JPA 표준은 아니지만 코드 기반으로 단순하고 사용하기 쉬움
  • Criteria에 비해 간단한 펴
• 네이티브 SQL
  • 특정 DB에 의존하는 기능을 사용해야할 때, 직접 SQL을 사용하고 싶을때 사용하는 기능
  • JPA를 쓰면서 네이티브 SQL을 실행할 수 있다
• JDBC 직접 사용하고, 마이바티스 같은 SQL 매퍼 프레임워크 사용
  • 하이버네이트에서 직접 JDBC 커넥션을 획득해서 사용할 수 있음
  • 대신 영속성 컨텍스트를 적절한 시점에 강제 플러시해야함
  • Spring을 사용한다면 AOP를 활용해 DB접근 메소드를 호출할 때마다 컨텍스트를 플러시 할 수 있음

JPQL

• SELECT 문
  • 대소문자 구분함 (엔티티, 속성)
  • 클래스 명이 아닌 엔티티 이름 사용
  • 별칭을 반드시 주어야함 (대신 AS 키워드는 생략 가능)
  • 파라미터 바인딩
    • 이름 기준으로 파라미터를 구분할 수 있음 (파라미터 앞에 :를 추가)
    • 위치 기준 파라미터 (파라미터 가 들어가야할 곳에 ?<순서>로 지정 e.g. ?1, ?2)
• 프로젝션
  • SELECT절에 조회할 대상을 지정하는 것
• 페이징 API
  • 페이징 처리용 API를 사용하면 DB에 맞게 페이지네이션하는 쿼리를 사용함
  • 튜닝이 필요하면 네이티브 SQL을 직접 사용해야함
• 집합과 정렬
  • GROUP BY를 사용한 쿼리들도 JPQL로 정의 가능
• JPQL 조인
  • 내부조인, 외부조인, 컬렉션 조인, 세타 조인, 페치 조인 가능
  • 컬렉션 조인 : 일대다 or 다대다 관계처럼 컬렉션을 사용하는 곳에 조인하는 것
  • 세타 조인 : WHERE 조건을 확인해서 조인 시점에 조인 대상을 필터링하는 조인

[minkukjo]

끄저 끄적

• 엔터티를 조회할 수 있는 두 가지 방법
  • EntityManager.find()
  • 객체 그래프 탐색 a.getB().getC()
• JPQL은 얼핏 SQL과 비슷해 보이지만, JPA에서 객체 지향적으로 쿼리할 수 있게 지원해주는 쿼리 문법.
• JPQL의 철학은, 엔티티 객체를 조회하기 위한 객체지향 쿼리이며 특정 DB에 종속적이지 않아서 DB를 바꾼다 하더라도 쿼리 자체는 그대로 유지할 수 있게 하는 것에 그 목적이 있다.
• Criteria 쿼리는 JPQL을 생성하는 빌더 클래스이다. (써본적 없음)
  • query.select(m).where(...)처럼 프로그래밍 가능하다는데, QueryDSL 대비 어떤 장점이 있는거지?
  • 하고 찾아봤더니 Criteria 쿼리는 아래처럼 만들어짐
  • 직관적이지 않음.

//Criteria 사용준비
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Member> query = cb.createQuery(Member.class);

//루트 클래스 (조회를 시작할 클래스)
Root<Member> m = query.from(Member.class);

//쿼리생성
CriteriaQuery<Member> cq = query.select(m).where(cb.equal(m.get("username"), "회원");
Member member = em.createQuery(cq).getMember();

• QueryDSL은 JPA 표준은 아니지만, 스프링 재단도 Criteria보단 QueryDSL을 표준으로 선정해야하는게 아닌가? 싶기도 함. 그 정도로 JPA + QueryDSL 조합은 국룰임
• 마이바티스는 쓰레기여서 언급하지 않겠음. 마이바티스를 쓰느니 그냥 네이티브 SQL을 쓰겠음.
• 희찬님이 말씀하신 JPQL에서 new쓰는 내용은 너무나 공감되는 부분이었음. 이런건 제발 애플리케이션에서 합시다!!
• 페치 조인이고 나발이고 그냥 JPA 연관관계는 가급적 쓰지 않는 편이 정신건강에 이롭습니다.

같이 논의해보면 좋을 토픽들

• 개인적으로 DB에 종속적이지 않는 것이 JPQL이 가져다주는 큰 이점은 맞는데, 그럼 되물어보고 싶다. 과연 상용 RDBMS를 바꾸는 일이 실무에서 얼마나 빈번한가?

  • DB를 바꿔야될 정도의 이슈면 대부분 DB의 부하가 너무 커져서 마이그레이션 해서 바꾸는 경우일텐데, 그런 경우라면 사실 애플리케이션 코드부터 SQL까지 다시 작성해야하는게 아닌지? ( 현재 페이가 오라클 -> MySQL 전환을 시도중이라고 들음 )

• QueryDSL을 쓰면 필연적으로 Projection 객체를 만들어야할텐데요. 다른 분들은 이 때 만들어지는 Projection 객체명은 어떻게 만드시는지 궁금합니다. (현재 저희 팀 토픽 중 하나라서요)

• Criteria 파트는 그냥 넘기면 어떨까요? 앞으로 Java 개발자로 커리어 하면서 쓰는걸 볼 일이 없을 것 같아서 제안드려봅니다. (_ _)

[HaeUlNam]

10장 객체지향 쿼리 언어

끄적끄적

• JPQL(Java Persistence Query language): Entity 객체를 조회하는 객체지향 쿼리
  • SQL을 추상화해서 특정 데이터베이스에 의존하지 않는다. Dialect만 변경하면 JPQL을 수정하지 않더라도 자연스럽게 데이터베이스 변경 가능.

// JPQL
select m
from Member as m
where m.username = 'kim'

// 실제 실행된 SQL
select 
	member.id as id,
	member.age as age,
	member.team_id as team,
	member.name as name
from 
	Member member
where
	member.name = 'kim'

• Criteria 쿼리: JPQL을 생성하는 빌더 클래스
  • 장점: 문자가 아닌 프로그래밍 코드로 JPQL을 작성할 수 있다는 점
    • 컴파일 타입 detect, 코드 자동완성, 동적 쿼리 작성 편리
  • 단점: 장점을 상쇄할 정도로 복잡하고 장황하다
• QueryDSL: Criteria보다 훨씬 단순하고 사용하기 쉬움

//준비
JPAQuery query = new JPAQuery(em);
QMember member = QMember.member;

//쿼리, 결과조회
List<Member> members = query.from(member)
	.where(member.username.eq("kim"))
	.list(member);

• Native SQL: SQL Hint와 같이 특정 데이터베이스에 의존하는 기능을 사용해야 할 때나 사용

JPQL details

• SELECT 문: 별칭은 필수
• JPQL을 실행하려면 쿼리 객체가 필요함
  • TypeQuery: 반환할 타입을 명확하게 지정할 수 있으면
  • Query: 반환할 타입을 명확하게 지정할 수 없으면
• Parameter 바인딩: 이름 기준 파라미터가 위치 기준 파라미터보다 더 명확
  • Parameter 바인딩을 이용하지 않고, 직접 문자를 더해 만들면 악의적인 사용자에 의해 SQL 인젝션을 당할 수 있다.
  • Parameter 바인딩을 사용하면 파라미터의 값이 달라도 같은 쿼리로 인식해서 파싱한 결과를 재사용할 수 있다.

//이름 기준 파라미터
TypedQuery<Member> query = em.createQuery("SELECT m FROM Member m where m.username = :username",
Member.class);

query.setParameter("username", "User1");

//위치 기준 파라미터
List<Member> query = em.createQuery("SELECT m FROM Member m where m.username = ?!",
Member.class)
	.setParameter(1, "User1")
  .getResultList();

• 프로젝션: 조회할 대상을 지정하는 것
• 페이징 API: 같은 API로 paging 처리를 해서 Dialect에 따라 적절한 DB로 변환
  • Mysql pagination in mysql
    • Offset keyword는 N row를 skip하는 것이 아니라 읽고 discard한다. 그렇기에 Row가 많으면 많을 수록 성능이 좋진 않을 수 있다.
    • 따라서, Row가 많을 경우 WHERE절을 통해 N row를 skip하고, Cursor pagination를 사용하는 게 성능상 좋음. 다만 Offset 방식보다 다소 복잡하기에 필요한 경우에만 쓰면 될 것 같다.
    • https://planetscale.com/blog/mysql-pagination#drawbacks-to-cursor-based-pagination