<aside> ❗

SQL 중심적인 개발의 문제점

• 애플리케이션은 객체 지향 프로그래밍을 많이 사용
• 데이터베이스는 관계형 DB를 많이 사용한다.
• 즉, 현재 시대는 객체를 관계형 DB에 관리하는 시대

CRUD 무한 반복, 지루한 코드

• 객체 필드 추가 시 쿼리문을 모두 바꿔야 함
• SQL에 의존적인 개발을 피하기 어려워짐

[패러다임의 불일치]

객체와 관계형 DB 테이블이 비슷하면서도 굉장히 다르다.

• 객체 지향 프로그래밍은 추상화, 캡슐화 정보은닉, 상속, 다형성 등 시스템의 복잡성을 제어할 수 있는 다양한 장치들을 제공
• 실무에서는 객체를 저장하기 위해 RDB를 주로 선택하게 됨 NoSQL은 보조적으로 많이 사용

객체 → SQL 변환 → SQL → RDB에 저장 개발자가 이 작업을 수행하게 됨 (개발자가 SQL 매퍼가 됨)

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

1. 상속
2. 연관관계
3. 데이터 타입
4. 데이터 식별 방법

상속

• RDB는 상속 관계가 없다.
• 슈퍼 타입, 서브 타입 관계를 만들어서 상속과 비슷하게 구현 가능 비슷하지만 객체와 비교하면 다르다.
• 쿼리로 이를 작성하려면 쉽지 않음
  • 저장시, 부모 객체, 자식 객체의 데이터를 따로 저장하기 위해 분리해야 함
  • 각각 Insert 해야 한다.
  • 조회 시, 각각의 테이블에 따른 조인 SQL 작성해야 한다. → 부모 객체 + 조회하고자 하는 객체의 데이터가 모두 필요하기 떄문
• 자바 컬렉션을 사용해서 부모 타입 검색해서 할 수 있다면 편하게 사용할 수 있을 것

연관관계

• 객체는 참조를 사용하여 연관관계를 맺는다. Ex) 멤버 객체 안에 팀 타입 참조변수 필드
• 테이블은 외래 키를 사용헤서 조인해야 한다. - JOIN ON M.TEAM_ID = T.TEAM_ID 객체 참조가 없기 때문
• 객체를 테이블에 맞춰서 모델링하게 될 수 밖에 없음 → SQL에 의존적인 개발을 하게 됨 // 객체다운 모델링하기 어려워짐 (DB에 넣기 어려움)

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

class Team {
	Long id;      // TEAD_ID PK 사용 
	String name;  
}

• 객체는 참조로 연관관계를 맺는다.

class Member {
	String id;
	Team team;
	String username;
	

	Team getTeam() {
		return team;
	}
}

class Team {
	Long id;
	String name; 
}

[객체 그래프 탐색]

• 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 한다.
• 즉, 참조로 따라갈 수 있어야 한다.
• **처음에 어떤 SQL문을 실행하느냐에 따라 탐색 범위가 결정**된다.
  • DAO나 리포지토리에 어디 까지 세팅하느냐에 따라 탐색 범위 결정 → 엔티티 신뢰 문제 발생
  • 계층형 아키텍처란 우리가 다음 계층을 믿고 쓸 수 있어야 함

class MemberService {
	public void process() {
		Member member = memberDAO.find(memberId);
		member.getTeam();  // Team을 가져올 수 있나 ?? DB에 따로 저장되는데 ??
		member.getOrder().getDelivery(); // ??? // Delivery까지 참조가 가능한가 ??
		// MemberDAO를 어떻게 작성했는지에 따라 달라지므로 DAO를 봐야함 
	}
}

• 모든 객체를 미리 로딩할 수는 없음 → 객체 그래프를 따라갈 수 있게 작성할 수는 있으나 너무 어려움 → 너무 어마어마한 쿼리가 나오고(매우 복잡), 사용하지 않는 데이터도 조회하므로 성능도 안 좋음 → 이를 해결하기 위해 상황에 맞게 조회 메서드 여러 개 생성

memberDAO.getMember(); // Member만 조회
memberDAO.getMemberWithTeam(); // Member와 Team 조회
// Member, Order, Delivery - 경우의 수가 많으므로 다 구현해야 함...
memberDAO.getMemberWithOrderWithDelivery();

• 즉, 진정한 의미의 계층 분할이 어렵다. 물리적으로 분할되어 있으나 논리적으로 엮여있게 됨
• 계층형 아키텍처랑 다음 계층을 믿고 내가 쓸 수 있는 것을 말함

[비교하기]

• SQL 사용 시 동일한 값을 가지고 있지만, 인스턴스가 같지 않는 문제 발생
• 자바 컬렉션에서 조회하게 되면 두 인스턴스가 같다고 나온다.

객체답게 모델링 할수록 매핑 작업만 늘어나게 됨

객체를 SQL로 변환하는 작업의 비용이 너무 큼

객체를 자바 컬렉션에 저장 하듯이 DB에 저장하기 위해 JPA 등장

</aside>