'백엔드 개발/데이터베이스' 카테고리의 글 목록
게으른 개발자
백엔드 개발/데이터베이스
TypeORM Connection Pool로 DB 연결 안정성 확보하기
2025.04.22
TypeORM에서도 꼭 알아야 할 커넥션 풀(Connection Pool) 설정과 이유TypeORM은 커넥션 풀을 지원하나요?네, 기본적으로 지원합니다.TypeORM은 내부적으로 PostgreSQL 드라이버인 pg를 사용하며, 이 드라이버는 커넥션 풀 기능을 기본으로 제공합니다.설정은 extra 속성에 아래와 같이 추가하면 됩니다:const dataSource = new DataSource({ type: "postgres", host: "localhost", port: 5432, username: "user", password: "pass", database: "mydb", entities: [/* ... */], synchronize: true, logging: false, extra..
백엔드 개발/데이터베이스
[TypeORM 최신 문법] getRepository 제거 대응법
2025.04.21
TypeORM v0.3 이후 getRepository() 제거 – 최신 방식으로 바꾸는 법TypeORM에서 getRepository는 특정 엔티티의 리포지토리(Repository)를 가져오는 함수입니다.그러나 TypeORM v0.3.x 이상에서는 더 이상 getRepository()를 사용하지 않고dataSource.getRepository()를 사용해야 합니다.getRepository란?TypeORM에서는 엔티티(Entity)를 조작하기 위해 리포지토리(Repository) 개념을 사용합니다.기본적으로 데이터베이스에서 CRUD(생성, 읽기, 수정, 삭제) 작업을 수행하는 객체입니다.import { getRepository } from "typeorm";import { User } from "../ent..

백엔드 개발/데이터베이스
[EPL 자동 업데이트 시스템 구축기] 경기 결과 기반 DB 업데이트 플로우 & 쿼리 예제
2024.03.07
EPL 경기 결과를 DB에 자동 업데이트하는 시스템, 어떻게 만들었을까?매일 새벽 12시, 오늘 치러진 EPL 경기 결과를 기준으로클럽별 누적 전적을 DB에 자동 업데이트하는 간단한 API를 구성했습니다.이 포스트에서는 데이터 처리 흐름부터, 실제 쿼리 작성 전략까지 정리해보았습니다. 목적 크롤링한 EPL 경기 결과 + 기존 클럽 DB 정보→ 오늘 경기 기준으로 클럽별 총 전적 자동 반영→ 스케줄러 기준 00:00에 수행사용 데이터1. 크롤링 데이터 (PremierLeagueData)- 팀명 team, 순위 ranking, 경기수 totalMatches- 승/무/패 win/draw/lose, 득실점 score/conceded- 득실차 gainLossDifference, 승점 point, 최근5경기 las..
백엔드 개발/데이터베이스
MySQL INSERT 중복 처리 정리 – IGNORE vs ON DUPLICATE KEY UPDATE 언제 써야 할까?
2024.01.02
INSERT 구문 비교: ON DUPLICATE KEY UPDATE vs INSERT IGNORE유지보수 도중, 기존에 사용된 Raw Query를 분석하며 두 가지 구문 간의 차이를 정리해보았습니다.INSERT ... ON DUPLICATE KEY UPDATEMySQL에서 유니크 또는 프라이머리 키 충돌이 발생할 경우, 해당 행을 업데이트하는 구문입니다.INSERT INTO table_name (column1, column2, ...)VALUES (value1, value2, ...)ON DUPLICATE KEY UPDATE column1 = value1, column2 = value2;새로운 행 → 삽입중복 키 충돌 → 기존 행 업데이트복합 키 또는 고유 키 조건에서도 유용중복 시 처리할 로직이..
백엔드 개발/데이터베이스
SQL 최적화 실전 비교 – SELECT 두 번 쓸까 JOIN 한 번 쓸까
2024.01.02
SELECT 2번 vs SELECT ... LEFT JOIN – 어떤 게 더 효율적일까?데이터를 가져올 때 단순히 두 번의 SELECT 쿼리를 날리는 방식과한 번의 LEFT JOIN으로 처리하는 방식은 성능, 가독성, 유지보수 측면에서 차이가 있습니다.SELECT 2번 방식SELECT * FROM users WHERE id = 1;SELECT * FROM orders WHERE user_id = 1;각각 독립적인 쿼리로 수행됨코드 흐름은 직관적일 수 있음여러 테이블을 조건 분리하여 명확하게 처리 가능하지만 응답 횟수가 많아질수록 네트워크 비용 증가SELECT ... LEFT JOIN 방식SELECT users.*, orders.*FROM usersLEFT JOIN orders ON users.id = o..