객체와 테이블 매핑
연관관계 매핑
member / team
객체와 테이블 매핑
@Entity
엔티티가 붙은 클래스는 JPA 관리 엔티티
JAP를 사용해서 테이블과 매핑할 클래스는 @Entity 필수
기본 생성자 필수 (파라미터가 없는 Public 또는 protected 생성자)
final 클래스 enum , interface , inner 클래스 사용 X
저장할 필드에 final 사용 X
주로 쓸일이 없지만 같은 클래스에 다른 이름으로 매핑이나 구분할 때 사용
@Table
DB에서 member라고 쓰지말고 MBR 이라는 테이블로 써야되요!
이럴때
데이터베이스 스키마 자동 생성
DDL을 애플리케이션 실행 시점에서 자동 생성한다.
테이블 중심 -> 객체 중심
데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
이렇게 생성된 DDL은 개발 장비에서만 사용
생성된 DDL은 운영서버에서는 사용하지 않거나 적절히 다듬은 후 사용
데이터베이스 스키마 자동 생성 - 주의
운영 장비에는 절대 create, create-drop ,update 사용하면 안된다.
개발 초기 단계는 create OR update
테스트 서버는 update OR validate
스테이징과 운영 서버는 validate OR none
로컬에서만 Create /update
나머진 validate...
DDL 생성 기능
유니크 제약 조건을 넣거나 이런건 실행 영향을 주지 않고
DDL 생성 영향에만 준다.
필드와 컬럼 매핑
객체는 userName 이지만 디비에는 name으로 되있어서 설정
@Enumerated(EnumType.STRING)디비에는 이넘 타입이 없어서 스트링으로 변환..
Lob -> vachar 보다 큰 컨텐츠를 넣을때
문자타입은 clob
디비랑 관계없이. 메모리에만 쓰고싶을때
unique 잘안씀 생성시 이름이 이상하게되서.
@Enumerated
ORDINAL 사용 XXXXX
이넘의 순서를 디비에 저장하는 것임 IntegerType 으로 들어간다.
EnumType.String만 사용 해야됨.
Temporal
LocalDate(년,월) , LocalDateTime(년월일) 쓰면 생략가능하다.
Lob
지정하는 속성이 없기 때문에 문자열은 Clob 나머지 blob
기본 키 매핑
@Id //내가 직접 할당 할거야
@GenernateValue // 자동매핑
@GenernateValue Generation.Auto // DB 방언에따라 자동으로
IDENTITY
-- DB가 알아서 해줘..
mysql
아이디 값을 알 수 있는 시점이 디비에 값이 들어 갔을때 알수 있다
그런대 영속성 컨텍스트를 사용하려는데 제약이 생겨 버린다.
jdbc 드라이버에 insert 쿼리를 했을때 내부적으로 바로 알 수 있는 게 있어서
JPA가 내부적으로 들어와서 바로 findID 알수있다.
결론: 모아서 인서트하는게 불가능함.
Sequence
int , Integer 는 애매함 (10억 넘어가면 돌기때문에)
Long 으로 ( 요즘은 성능영향이 미미하기 때문에 Long으로 쓴다)
따로 시퀀스마다 이름을 정해줘도 된다.
이 방법도 디비의 다녀와야 ID값을 알 수 있다.
다음 값 내놔! 한 다음 인서트
버퍼링 가능 .
allocationSize
미리 값을 50개 땡겨와서 미리 확보해놈
여러 와스에서 동시성 이슈없이
TABLE 전략
키 생성 전용 테이블을 하나 만들어서 데이터베이스 시퀀스를 흉내내는 전략
장점: 모든 데이터베이스에 적용 가능
단점: 성능 .
디비에서 쓰는 관례가 있어서 딱히 쓰지않는다..
권장하는 식별자 전략
기본키 null / 유일 / 불변
하지만 변하지않는 경우 때문에 미래까지 이 조건을 만족하기 힘듬.(자연키)
대리키(대체키) -> ex)AutoIncreament ,sequence 같은거.. 디비에서 자동으로 증가하는 사용하자!
권장: Long형 + 대체키(sequence) + 키 생성 전략 사용
실전 예제 - 1. 요구사항 분석과 기본 매핑
회원은 상품을 주문하고
주문시 여러종류의 상품을 주문 할 수 있따.
처음에는 보통 테이블 = 객체 설계 매핑이 같다.
엔티티에 주로 매핑정보? 컬럼정보 적어두면 다른사람이 보기 편하다.
컬럼명이 단순히 소문자로 되있는대 ORDER_DATE / order_date 이런식으로 변경 해주면된다.
스프링 부트에서는 기본 설정을 order_date 자바의 카멜 케이스를 읽어서.. 언더스코어로감
객체지향 스럽지 않네..
이런식으로 ..
왜 이런 문제가? 관계형 디비에 맞춰서 객체를 설계했기때문에.
테이블의 외래키를 객체에 그대로 가져오니
객체 그래프 탐색이 불가능
참조가 없음으로 UML이 잘못됨.
