1. SQL 중심적인 개발의 문제점

SQL 중심적인 개발의 문제점

CRUD의 무한 반복, 지루한 코드. 더불어 필드가 추가되면 SQL 쿼리문을 전체적으로 뜯어고쳐야 한다. 이는 매우 비효율적

(다만, SQL에 의존적인 개발을 피하기는 어렵다.)

---

패러다임의 불일치

회원 정보를 저장할 때 객체 vs 관계형 데이터베이스 ➡  현실적인 대안은 관계형 데이터베이스

객체를 관계형 데이터베이스에 저장

위와 같은 과정 == SQL 매핑하는 것이 개발자의 역할!

 

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

1) 상속

상속관계는 DB에 저장할 수 없다. 관계형 데이터베이스에서 테이블을 만들어서 조인하는 것 == 슈퍼타입 서브타입 관계

 

DB에 저장할 객체에는 상속 관계를 쓰지 않는다. 그 이유는... 예를 들어

Album 저장 :

객체를 분해(name, price, dtype, artist라는 정보가 필요) ➡ INSERT INTO ITEM ... ➡ INSERT INTO ALBUM ...

 

Album 조회 :

item과 album 테이블을 조인하는 SQL 작성 ➡ 각각의 객체 생성 ➡ ... 너무 복잡

 

자바 컬렉션에 저장하면? list.add(album)

 

2) 연관 관계

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

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

 

객체를 테이블에 맞춰 모델링

 

BUT..!!

객체다운 모델링은 아래와 같다.

그러나 team_id가 member에 없기에 team_id를 가져오기 굉장히 까다로워진다.

또한 조회 시 복잡한 과정을 거쳐야 한다.

 

반면 객체로 모델링하고 자바 컬랙션에서 관리하면 아래 코드로 모든 것이 가능하다!

list.add(member); 			# 멤버 정보 저장
Member member = list.get(memberId); 	# memberId 꺼내기
Team team = member.getTeam();		# team이 뭔지 알아내기

 

객체는 자유롭게 그래프를 탐색할 수 있어야 한다. 그러나.. 

member.getTeam(); //OK 
member.getOrder(); //null

계층이 성립하지 않아서 엔티티 신뢰 문제가 발생

class MemberService {
	...
	public void process() {
	Member member = memberDAO.find(memberId);
	member.getTeam(); //???
	member.getOrder().getDelivery(); // ???
	}
}

 

모든 객체를 미리 로딩할 수는 없다. 상황에 따라 동일한 회원 조회 메서드를 여러 벌 생성하면 된다.

memberDAO.getMember(); // Member만 조회 
memberDAO.getMemberWithTeam();// Member와 Team 조회

//Member,Order,Delivery - 길어짐..
memberDAO.getMemberWithOrderWithDelivery();

 

즉, 진정한 의미의 계층 분할은 사실상 어렵다.

 

비교하기  

데이터는 같지만, 서로 다른 인스턴스를 생성하는 것.

String memberId = "100";
Member member1 = memberDAO.getMember(memberId);
Member member2 = memberDAO.getMember(memberId);
member1 == member2; //다르다.

 

but 비교하기 - 자바 컬렉션에서 조회 인스턴스가 같게 도출됨.

String memberId = "100";
Member member1 = list.get(memberId);
Member member2 = list.get(memberId);
member1 == member2; //같다.

 

객체답게 모델링할 수록 매핑 작업만 늘어난다..

객체를 자바 컬렉션에 저장하듯이 db에 저장할 수는 없을까?

JPA : Java Persistence API