간단 정리정규화란 데이터를 안전하게 관리하기 위한 설계 방법이다. 제1 정규화는 한 컬럼에 하나의 데이터만 존재하도록 만드는 것이다.제2 정규화는 제1 정규화 + 현재 테이블의 주제와 관련이 없는 컬럼을 분리(다른 테이블)하는 것이다.제3 정규화는 제2 정규화 + 일반

인덱스란 데이터베이스에서 검색 성능을 향상시키기 위해 사용하는 자료구조이다.마치 책의 목차처럼 특정 데이터를 빠르게 찾을 수 있도록 도와준다. 인덱스가 없을 경우, 데이터베이스는 원하는 데이터를 찾기 위해 전체 테이블을 조회(Full Table Scan)해야 하지만,

저장공간에 값을 저장(할당)하는 법변수를 선언하고 언제든 값을 덮어씌울 수 있다.(바꿀 수 있다)상수를 선언하면 그 이후로는 값을 바꿀 수 없다.메모리는 0과 1로만 이루어진다. 그럼 문자는 어떻게 저장될까? 바로 아스키코드를 통해 숫자로 변환하여 저장한다.예시)

실수 와 부동 소수점실수 표현과 부동 소수점에 대해 이해하기 위해서는 먼저 '실수'와 '부동 소수점'이 무엇인지 알아야 합니다.실수(Real Number):실수는 소수점이 있는 숫자를 말합니다. 예를 들어, 3.14, 0.01, -2.5 등이 실수입니다. 이러한 실수는

맨 처음 보는 코드 분석하기

제네릭은 자바에서 데이터 타입을 일반화하는 방법으로, 컴파일 시에 타입을 미리 지정하여 타입 안정성을 높이고 불필요한 타입 변환을 줄입니다1. 제네릭의 주요 장점은 다음과 같습니다:타입 안정성 보장불필요한 형 변환 제거코드 재사용성 증가제네릭 타입은 컴파일 시점, 즉

싱글톤 패턴은 객체를 하나만 생성하여 애플리케이션 전체에서 공유할 수 있도록 하는 디자인 패턴입니다.특징하나의 인스턴스만 생성됨전역적으로 접근 가능메모리 절약 및 데이터 공유 용이하지만 위 방식은 멀티스레드 환경에서 안전하지 않기 때문에 double-checked lo

초기 구현에서는 데이터베이스에서 직접 쿼리를 수행하여 "실시간 웨이팅 순서"를 계산했습니다.예를 들어, 아래와 같이 특정 가게와 날짜, 그리고 본인의 웨이팅 번호보다 앞에 있는 대기 중인 팀의 수를 DB에서 직접 카운트하는 방식입니다.문제점:DB 부하 증가: 실시간으로

데이터 수가 증가함에 따라 현재 Store 엔티티와 연관된 검색 기능에서 성능 문제가 발생하고 있습니다.searchStoreQuery 메서드에서 다수의 조인과 조건 필터링이 이루어지며 응답 속도가 저하됩니다. 이로 인해 사용자가 검색 결과를 확인하는 데 시간이 오래 걸

SSE (Server-Sent Events)를 React 애플리케이션에 적용하면서 발생한 문제들과 해결 방법을 정리SSE를 알림기능에 사용하기 위해 전역 페이지에 적용함.SSEProvider가 App.js의 Router 전체를 감싸고 있어 로그인/회원가입 페이지에서도

초기에는 엑세스토큰만을 사용하여 로그인을 관리했는데, 엑세스토큰의 만료 시간이 짧아 사용자가 자주 로그인을 다시 해야 하는 불편함이 발생했습니다.즉, 사용자가 로그인한 후에도 짧은 시간마다 토큰 만료로 인해 인증이 끊기고, 다시 로그인을 해야 하는 상황이 문제였습니다.

🟩장점다양한 결제 수단 지원💳 : 신용카드, 가상계좌, 계좌이체, 휴대폰 결제 등 다양한 결제 옵션을 제공API 안정성 높음🔒 : 오랜 기간 운영된 PG사인만큼 장애 발생 가능성이 적음정기 결제 & B2B 기능 제공📅🔄 : 정기 결제, 자동 결제 같은 고급 기

프로젝트 배포 파이프라인을 구축할 때, Jenkins와 GitHub Actions 두 가지 옵션을 검토했습니다. 여러 측면에서 비교한 결과, GitHub Actions를 선택한 주요 이유는 다음과 같습니다.GitHub Actions:GitHub Actions는 GitH

서비스에서는 사용자가 특정 가게 상세 조회 페이지에 진입하면 해당 가게의 조회수가 증가하고, 페이지를 벗어나면 감소하는 동적 기능이 필요합니다. 이를 위해 여러 통신 기술(SSE, WebSocket, RabbitMQ, Kafka)을 고려하였으며, 각 기술의 장단점을 아

프로젝트 설계

build.gradlebuild.gradle에 dependencies 안에 queryDSL 의존성 추가한다.Gradle의 Task에서 build > clean ->other > compileJava 과정을 차례로 수행해보자.다음 사진과 같이 build 디렉터리에 Ent

먼저 Querydsl과 JPQL을 비교해보겠다.Querydsl vs JPQLEntityManager 로 JPAQueryFactory 생성Querydsl 은 JPQL 빌더JPQL: 문자(실행 시점 오류), Querydsl: 코드(컴파일 시점 오류)JPQL: 파라미터 바인

JPA를 사용하여 데이터베이스와 연결된 애플리케이션을 개발할 때, 동시성 처리와 관련된 이슈가 발생할 수 있다. 이러한 이슈를 해결하기 위한 방법 중 하나는 락(lock)을 사용하는 것이다. 이번 포스팅에는 낙관적 락과 비관적 락에 대해 알아보고, 예제코드와 이를 사용

Trello에서 멤버는 특정 키워드로 카드를 검색하거나, 프로젝트별로 카드를 필터링하고 있습니다. 하지만 데이터가 대량으로 축적됨에 따라 카드 검색 속도가 느려질 수 있습니다. 카드 검색 속도를 향상시킬 수 있는 최적화 방법을 적용해주세요. 요구사항카드 검색 속도를 향

intro프로젝트를 하는 과정에서 많은 데이터의 상태를 모두 변경해야되는 문제에 직면했다.예를 들어, 사람들이 신고한 사용자의 id를 하루동안 받았다가 한 번에 처리할 때나 쿠폰이 만료 기간이 지나서 한번에 상태를 만료로 변경해야 할 때가 있다.수 백만 건의 데이터를