SQL 중심적인 개발의 문제점

OOP로 설계하면 자바 컬렉션에 저장과 조회를 간편하게 할 수 있고, 다형성을 활용해서 비즈니스 로직 코드를 쉽게 작성할 수 있다. 하지마 이렇게 OOP로 작성된 데이터를 RDB에 저장하려고 할때 문제가 나타난다! SQL 문이 매우 복잡해지고 반복작업을 해야하기 때문이다!

그렇다면 코드를 테이블 지향적으로 설계하면 어떻게 될까? 다음처럼 코드를 작성하면 DB에 객체를 저장할 땐 SQL문이 정말 단순해진다! 하지만 로직 구현한 이 코드는 좋은 코드가 아니다. 왜냐하면 Member와 Team이 연관관계가 있다면 이 둘을 클래스로 각각 만들어서 '.' 연산자로 조회하는 것이 적절한데 저렇게 Member 필드에 Team 데이터가 있으면 OOP의 장점을 이용하지 못하면서 실용성이나 사용성이 매우 떨어지게 된다!!

=>패러다임 불일치로 인해 생산성이 떨어지고 유지보수가 어려워진다!!

class Member {
    String id; //MEMBER_ID 컬럼 사용
    Long teamId; //TEAM_ID FK 컬럼 사용 //**
    String username;//USERNAME 컬럼 사용
}

결국 객체 지향으로 설계하면 SQL 매핑 작업만 늘어나게 된다! 객체를 자바 컬렉션에 저장, 조회하듯이 DB에 저장, 조회할 수는 없을까? 하는 자연스러운 관심과 필요에 의해 자바 ORM 표준 JPA가 등장하게 된다!

객체와 관계형 데이터베이스의 차이

1. 상속

2. 연관관계 ex)자바 - getXXX

3. 데이터 타입

4. 데이터 식별 방법

객체 상속 관계

Table 슈퍼타입 서브 타입 관계

1. 상속 자바 컬렉션에 저장, 조회

list.add(album);
Album album = list.get(albumId);
//부모 타입으로 조회 후 다형성 활용
Item item = list.get(albumId);

2. 연관관계

• 객체는 참조를 사용: member.getTeam()

• 테이블은 외래 키를 사용: JOIN ON M.TEAM_ID = T.TEAM_ID⭐️⭐️⭐️⭐️⭐️

객체를 테이블에 맞추어 모델

class Member {
    String id; //MEMBER_ID 컬럼 사용
    Long teamId; //TEAM_ID FK 컬럼 사용 //**
    String username;//USERNAME 컬럼 사용
}

테이블에 맞춘 객체 저장

INSERT INTO MEMBER(MEMBER_ID, TEAM_ID, USERNAME) VALUES ...

객체다운 모델링 Member 클래스에서 Team과 연관관계를 맺고, member.getTeam()으로 자유롭게 데이터 조회할 수 있다.

class Member {
  String id; //MEMBER_ID 컬럼 사용
  Team team; //참조로 연관관계를 맺는다. //**
  String username;//USERNAME 컬럼 사용
   Team getTeam() { 
     return team;
   }
}
class Team {
  Long id; //TEAM_ID PK 사용
  String name; //NAME 컬럼 사용
}

객체 모델링 저장

INSERT INTO MEMBER(MEMBER_ID, member.getTeam().getId();, USERNAME) VALUES ...

객체 모델링 조회

OOP를 하면 데이터 저장과 조회가 자유롭게 설계 가능한데 DB에 객체를 저장할 때는 복잡한 SQL 작업이 반복된다. 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 한다. 하지만 SQL 의존적으로 설계하게 되면 처음 실행하는 SQL에 따라 탐색 범위가 결정된다.

SELECT M.*, T.* 
  FROM MEMBER M
  JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID

엔티티 신뢰 문제

처음에는 Member와 Team 데이터만 가지고 SQL 문을 작성한다. SQL에 따라 탐색 범위는 Member와 Team에 한정된다. 하지만 중간에 비즈니스 로직으로 인해 order가 추가된다면 처음에 SQL 실행할 때는 Member, Team 테이블만 채웠기 때문에 이 order를 조회해보면 존재하지 않는 null을 가리키게 된다! 어떠한 SQL문이 작성되는지에 따라 반환되는 결과가 달라지기 때문에 이러한 이유로 엔티티 신뢰 문제가 발생한다!

1차 해결방안 : 각각의 경우에 대해 메서드를 다 따로 작성한다.

memberDAO.getMember(); //Member만 조회 memberDAO.getMemberWithTeam();//Member와 Team 조회 memberDAO.getMemberWithOrderWithDelivery();//Member,ORder,Delivery 조회

=>모든 객체를 미리 로딩할 수는 없다 : 상황에 따라 동일한 회원 조회 메서드를 여러번 생성

비교하기 문제점

SQL쿼리문 통한 비교 : 다르다

자바 컬렉션에서 조회 : 같다