본문 바로가기

분류 전체보기

 (146)
즉시로딩과 지연로딩 멤버 조회할때 팀까지 조회해야하나? -지연 로딩 LAZY를 사용해서 팀 객체를 프록시로 가져옴 -@ManyToOne(fetch = FetchType.LAZY) -실제로 팀 객체의 메서드를 사용하는 시점 DB에 쿼리가 따로 나감(초기화) 멤버와 팀을 자주 함께 사용한다면? 즉시로딩 EAGER를 사용해서 같이 가져옴 @ManyToOne(fetch = FetchType.EAGER) 주의사항 -실무에선 무조건 지연 로딩만 사용 -즉시 로딩을 적용하면 예상하지 못한 SQL이 발생(JPQL에서 N+1 문제를 일으킴) -@ManyToOne, @OneToOne은 기본이 즉시 로딩 -> LAZY로 설정 바꾸는거 필수 -@OneToMany, @ManyToMany는 기본이 지연 로딩
프록시 프록시의 기초 em.find(): 데이터베이스를 통해서 실제 엔티티(진짜) 객체 조회 em.getReferrence(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 -DB에 쿼리가 안나가는데 저장이 된다? -> DB에 있는 값이 실제 사용되는 시점에 DB에 쿼리를 날림 프록시 특징 -실제 클래스를 상속받아서 만들어짐(겉모양이 같음) -사용자 입장에서 진짜인지 가짜인지 구분하지 않고 사용하면 됨 -프록시 객체는 실제 객체의 참조를 보관 -프록시 객체의 메서드를 호출하면 프록시 객체는 실제 객체의 메서드를 호출 -초기화 할때 없으면 영속성 컨텍스트에 초기화 요청하여 DB에서 가져와서 진짜 객체를 만들고 프록시 객체가 참조하여 연결시킴 -타입 비교 (==비교 대신 instance of 사용) ..
고급 매핑 상속관계 매핑 -RDB는 상속관계 X -슈퍼타입 서브타입 관계라는 모델링 기법이 객체상속과 유사하므로 매핑 상속관계 매핑 전략 -조인 전략(정석) -각각 테이블로 변환 -@Inheritance(strategy = InheritanceType.JOINED) -@DiscriminatorColumn (DTYPE 식별자 자동추가) -장점: 정규화, 외래키 참조 무결점 제약조건 활용(ITEM만 보면됨), 저장공간 효율화 -단점: 조인이 많이사용, 쿼리 많이 나감 -통합 테이블전략(싹 다 넣음): 단순할때 좋음 -기본값임(@Inheritance(strategy = InheritanceType.SINGLE_TABLE)) -DTYPE 필수(식별) -장점: 조인필요없음(빠름), 쿼리가 단순함 -단점: 자식 엔티티가 매핑..
연관관계 매핑 기초 연관관계가 필요한 이유 -객체를 테이블에 맞추어 데이터 중심으로 모델링하면, 협력관계를 만들수 없음 -테이블은 외래키로 JOIN을 사용해서 연관된 테이블을 찾는데 객체는 참조를 사용해서 연관관계를 찾음 -단방향 연관관계 지향(가급적 좋음) -객체 지향 모델링(연관관계 매핑(@JoinColumn)) 양방향 연관관계(반대 방향으로 객체 그래프 탐색) -테이블은 외래키로 다 조인할수 있음 -객체는 둘다 클래스 속성으로 가지고 있어야함 연관관계의 주인과 mappedBy -객체와 테이블의 연관관계 차이 -객체는 단반향이 두개 -테이블은 양뱡향 한개(외래키 조인) -둘중 하나로 외래 키를 관리해야함(외래키는 멤버객체를보고 바꿔야하나 팀 객체를 보고 바꿔야하나) 연관관계의 주인(Owner) -객체의 두관계중 하나를 ..
엔티티 매핑 객체와 테이블 매핑: @Entity, @Table @Entity가 붙은 클래스는 JPA가 관리하는 엔티티 -기본 생성자 필수 (@NoArgConstructor 사용하면 편리) -final , enum, interface, inner 클래스 사용 X 데이터 베이스 스키마 자동 생성 -DDL을 애플리케이션 실행 시점에 자동 생성 -데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성 -개발용임 (운영에서는 직접 만들어야함) 필드와 컬럼 매핑 -@Column: 컬럼 매핑 -insertable:등록 가능 여부 -updatable:수정 가능 여부 -nullable: not null 조건 -unique: 유니크 제약조건 -columnDefinition: 특정방언에 종속적인 정보 -@Temporal: ..
데이터 베이스 기본실습 스키마: 테이블(표)들를 그룹핑하는 일종의 폴더의 형태 데이터 베이스 서버: 스키마들의 집합 MySQL(Structured Query Language) -서버 실행 -mysql -uroot -p -스키마 생성 -CREATE DATABASE opentutorials; -스키마 삭제 -DROP DATABASE opentutorials; -스키마 보기 -SHOW DATABASES; -어떤 스키마를 사용할지 결정 -USE opentutorials; -현재 스키마에서 테이블 보기 -SHOW TABLES; CRUD CREATE -테이블 만들기 -CREATE TABLE topic( id INT(11) NOT NULL AUTO_INCREMENT, title VARCHAR(100) NOT NULL, description..
데이터베이스 데이터베이스 -특정 조직의 여러 사용자가 공유하여 사용할수 있도록 통합해서 저장한 운영데이터의 집합 -통합 데이터: 최소의 중복과 통제가능한 중복만 허용 -공유 데이터: 특정 조직의 여러 사용자가 함께 소유하고 이용 -저장 데이터: 컴퓨터가 접근할수 있는 매체에 저장된 데이터 -운영 데이터: 지속적으로 유지해야하는 데이터 데이터베이스의 특성 -실시간 접근: 실시간으로 응답 -계속 변화: CRUD를 통해 현재의 정확한 데이터 유지 -내용 기반 참조: 주소나 위치가 아니라 내용으로 참조 -동시 공유: 서로다른 또는 같은 데이터의 동시 사용 지원
영속성 관리 영속성 컨텍스트 -엔티티를 영구 저장하는 환경 -논리적인 개념 -엔티티 매니저를 통해서 영속성 컨텍스트에 접근 -엔티티 매니저와 영속성 컨텍스트가 1:1 대응 엔티티의 생명주기 -비영속(new/transient): 영속성 컨텍스트와 전혀 관계가 없는 새로운 형태 -영속(managed): 영속성 컨텍스트에 관리되는 상태 -준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태 -em.detach(): 특정 엔티티만 준영속 상태로 전환 -em.clear(): 영속성 컨텍스트를 완전히 초기화 -em.close(): 영속성 컨텍스트를 종료 -삭제(removed): 삭제된 상태 영속성 컨텍스트의 이점 -1차 캐시(DB가 아니라 먼저 1차 캐시에서 조회) -동일성(identity) 보장(1차 캐시) ..

티스토리툴바