미리 보는 인덱스 튜닝 특정 데이터를 찾는 방법은 크게 아래의 두 가지로 나뉜다. * 테이블 전체를 스캔한다. * 인덱스를 이용한다. 찾으려는 데이터가 중복이 많다면 전자가 빠를 것이고, 몇 안된다면 후자가 빠르다. 그리고 인덱스의 경우 큰

우선 개발 중인 서버의 요구사항은 아래와 같습니다. Chosung 이라는 테이블이 있고 해당 테이블에서 클라이언트에게 전달될 랜덤한 N개의 초성 데이터를 뽑아내야합니다. 아무래도 선택된 데이터들은 초성 게임에서 사용될 데이터들이니 최대한 빠른 응답성을 가져야 한다는 특징도

이전 포스팅 [https://hongchangsub.com/transactionwithjdbc/]까지 저희는 JDBC 기술에 의존하여 Transaction을 적용시켜 보았습니다.만약 현재의 상황에서 JDBC 말고 JPA를 사용한다고 가정하면 서비스 계층의 모든 트랜잭션 코드들이 모두 수정되어야 합니다.쉽게 말하면 디비

> 우선 해당 내용은 MVC 패턴 기반하에서 코드가 작성됩니다. 사실 저희가 사용하는 Spring이나 다른 프레임워크들은 아래에 나올 일련의 과정을 좀 더 수월하게 진행시켜주는 역할을 수행합니다. 본격적으로 프레임워크 없이 트랜잭션을 한번 구현해보겠습니다. > 본

개발을 하시면서 Transaction이라는 용어를 정말 많이 들어보셨을 것입니다.저 또한 용어의 정확한 의미는 모른채 사용했었습니다.예를 들어 “뭐 대충 데이터에 변경의 결과를 보장해준다는 거 아냐?” 정도의 느낌으로만 이해했습니다.혹시나 저와 같이 저런 느낌으로만

Connection Pool 저희는 JDBC를 이용해서 자바 어플리케이션에서 DB와 통신을 하고 데이터를 주고 받는 방법을 알아보았습니다.그러면 이제 조금 더 이론적인 내용에 대해 알아보겠습니다.아래의 코드에서 DriverManager를 통해서 Connection을 얻어오는 방식으로 DB와 통신을 진행하였습니다.

필자가 JDBC를 처음 사용해본것은 학교 교과목 중 데이터베이스라는 수업에서 사용해보았습니다.당시만 하더라도 저도 JPA를 공부하고 있던터라 “그냥 CRUD만 코드 따라쳐서 해봐야지”하고 간단하게 실습 후 넘어갔던 적이 있습니다.하지만 JPA를 사용해 어플리케이션을 만들고

이번 포스팅에서는 쓰면서도 헷갈리던 JPA의 Cascade 옵션에 대해서 정리하겠습니다.일단 기본적으로 Cascade라는 옵션이 등장하게 된 배경부터 알아봅시다. 아래의 코드를 보시죠 @Setter @Getter @Entity public class Parent { @Id @GeneratedValue private Long id; private String

지난번 포스팅의 Proxy를 활용해 JPA의 즉시로딩과 지연로딩에 대해서 알아봅시다. Member와 Team이 엔티티가 존재합니다.만약 Member를 조회할 때 Team 엔티티를 함께 조회하는 방식이 즉시로딩이고,Team 엔티티를 Proxy객체로 조회하는것이 지연로딩 방식입니다.아래 코드를 보면 직접