<aside> ❗

SQL 중심적인 개발의 문제점

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

CRUD 무한 반복, 지루한 코드

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

[패러다임의 불일치]

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

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

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

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

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

상속

• RDB는 상속 관계가 없다.
• 슈퍼 타입, 서브 타입 관계를 만들어서 상속과 비슷하게 구현 가능 비슷하지만 객체와 비교하면 다르다.
• 쿼리로 이를 작성하려면 쉽지 않음

연관관계

• 객체는 참조를 사용하여 연관관계를 맺는다. Ex) 멤버 객체 안에 팀 타입 참조변수 필드
• 테이블은 외래 키를 사용 - JOIN ON M.TEAM_ID = T.TEAM_ID

[객체 그래프 탐색]

• 객체는 자유롭게 객체 그래프를 탐색할 수 있어야 한다.
• 처음에 어떤 SQL문을 실행하느냐에 따라 탐색 범위가 결정된다. → 엔티티 신뢰 문제 발생
• 모든 객체를 미리 로딩할 수는 없음 → 객체 그래프를 따라갈 수 있게 작성할 수는 있으나 너무 어려움 → 너무 어마어마한 쿼리가 나오고(매우 복잡), 사용하지 않는 데이터도 조회하므로 성능도 안 좋음 → 이를 해결하기 위해 상황에 맞게 조회 메서드 여러 개 생성 즉, 진정한 의미의 계층 분할이 어렵다. 물리적으로 분할되어 있으나 논리적으로 엮여있게 됨
• 계층형 아키텍처랑 다음 계층을 믿고 내가 쓸 수 있는 것을 말함

[비교하기]

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

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

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

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

</aside>