[TIL] 스파르타 백엔드 캠프

오늘할일

1주차~3주차 강의

1주차

프로젝트 셋팅

<의존성>

- complie 시점 의존성 : 프로젝트를 컴파일 할때 사용, 즉 해당 라이브러리의 API를사용할 수 있습니다.

- runtime 시점 의존성 : 애플리케이션을 실행할 때 사용됩니다. 즉, 실행 시 에도 라이브러리가 필요

 

<의존성 옵션>

- implementation 옵션 : 직접적인 의존성을 추가할 때 사용, 이는 특정 라이브러리나 모듈이 프로젝트 컴파일 시 필요하지만, 해당 라이브러리가 프로젝트 외부로 공개될 필요가 없다는 것을 의미

-> 은닉성 : implementation으로 추가된 의존성은 다른 프로젝트 모듈에서 직접 접근할수 없습니다 이는 모듈 간의 캡슐화를 도와줍니다

- runtimeOnly 옵션 : complie 시점에는 필요없고 runtime 시점에만 필요한 라이브러리를 추가할 때 사용

-> 대표적으로 Logging 관련 라이브러리, DB관련 라이브러리

- testImplementation 옵션 : 테스트 코드를 수행할 때 적용할 라이브러리를 추가할 때 사용, 테스트 용도로만 라이브러리나 빌트인 DB를 사용하고 싶다면 해당 옵션을 사용

---

2주차

< H2>

자바로 작성된 관계형 데이터 베이스 관리 시스템

- H2 사용 방식 3가지

  - Server Mode : 직접 엔진을 설치하여 사용하는 방식 , 애플리케이션과 상관없는 외부에서 DB엔진이 구동, 데이터가 애플리케이션 외부에 저장되므로 애플리케이션을 종료해도 데이터가 사라지지 않는다. -> 배포 용도

  - In-memory Mode : 엔진을 설치하지 않고 애플리케이션 내부의 엔진을 사용하는 방식, 애플리케이션을 실행하면 DB엔진이 함께 실행되고 애플리케이션을 종료하면 DB엔진이 함께 종료 된다. 데이터가 애플리케이션 메모리에 저장되기 때문에 애플리케이션을 종료하면 데이터가 사라진다. -> 테스트 용도

# application.yml
spring:  
    datasource:    
        driver-class-name: org.h2.Driver
        url: jdbc:h2:mem:{DB 이름}
        username: sa
        password:
        
# application.properties
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:mem:{DB 이름}
spring.datasource.username=sa
spring.datasource.password=

  - Embedded Mode : 엔진을 설치하지 않고 애플리케이션 내부의 엔진을 사용하는 방식, 애플리케이션을 실행하면 DB엔진이 함께 실행되고 애플리케이션을 종료하면 DB엔진이 함께 종료된다 하지만 데이터가 애플리케이션 외부에 저장되므로 애플리케이션을 종료 해도 데이터가 사라지지 않는다 -> 개발 용도

# application.yml
spring:
  datasource:
      driver-class-name: org.h2.Driver
      url: jdbc:h2:{DB가 저장될 경로}    
      username: sa    
      password:
 
 # application.properties
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:{DB가 저장될 경로}
spring.datasource.username=sa
spring.datasource.password=

 

<트랜잭션>

데이터베이스의 상태를 변화시키기 위해 수행하는 작업의 단위

 

<데이터 베이스 연결>

- 드라이버

애플리케이션과 데이터베이스 간의 통신을 중계(데이터 교환을 조절하고 관리)하는 역할, 애플리케이션의 요청을 데이터베이스가 이해할 수 있는 언어로 변환 ex) Oracle, MySQL,PostgreSQL 

- 동작 방식

  연결 초기화 -> SQL 전송 및 실행 -> 결과 처리 -> 연결 종료

JDBC Driver Manager는 애플리케이션이 실행되고 있는 런타임 시점에

Connection을 생성하여 쿼리를 요청할 수 있는 상태를 만들어 주고

Statement를 생성하여 쿼리를 요청하게 해주고

ResultSet을 생성해 쿼리 결과를 받아 올수 있게 해줍니다.

---

3주차

<쿼리 파일 만들기>

 - MyBatis : RowMapper가 가지고 있는 단점인 반복적인 코드를 줄이고 함께 있는 프로그램 코드와 쿼리 코드를 분리하여 관리 하고 싶은 니즈를 반영하여 탄생

<쿼리 코드 만들기(JpaRepository)>

- QueryMapper의 DB의존성 및 중복 쿼리 문제로 ORM이 탄생

[ORM]이 해결해야 하는 문제점과 해결점

문제점

상속의 문제

• 객체 : 객체간에 멤버변수나 상속관계를 맺을 수 있다.
• RDB : 테이블들은 상속관계가 없고 모두 독립적으로 존재한다.

💁‍♂️ 해결방법 : 매핑정보에 상속정보를 넣어준다. (@OneToMany, @ManyToOne)

관계 문제

• 객체 : 참조를 통해 관계를 가지며 방향을 가진다. (다대다 관계도 있음)
• RDB : 외래키(FK)를 설정하여 Join 으로 조회시에만 참조가 가능하다. (즉, 다대다는 매핑 테이블 필요)

💁‍♂️ 해결방법 : 매핑정보에 방향정보를 넣어준다. (@JoinColumn, @MappedBy)

탐색 문제

• 객체 : 참조를 통해 다른 객체로 순차적 탐색이 가능하며 콜렉션도 순회한다.
• RDB : 탐색시 참조하는 만큼 추가 쿼리나, Join 이 발생하여 비효율적이다.

 💁‍♂️ 해결방법 : 매핑/조회 정보로 참조탐색 시점을 관리한다.(@FetchType, fetchJoin())

 

밀도 문제

• 객체 : 멤버 객체크기가 매우 클 수 있다.
• RDB : 기본 데이터 타입만 존재한다.

 💁‍♂️ 해결방법 : 크기가 큰 멤버 객체는 테이블을 분리하여 상속으로 처리한다. (@embedded)

 

식별성 문제

• 객체 : 객체의 hashCode 또는 정의한 equals() 메소드를 통해 식별
• RDB : PK 로만 식별

 💁‍♂️ 해결방법 : PK 를 객체 Id로 설정하고 EntityManager는 해당 값으로 객체를 식별하여 관리 한다.(@Id,@GeneratedValue )