DB

기본키는 레코드를 식별하고 테이블 관계를 설정하기 위해 필요하다.이 작업에서는 다음과 같은 부분을 고민했다.‘기본키를 자연키로 가져갈까 인조키로 가져갈까?’사실 다른 테이블들은 기본키로 구성할만한 자연키가 마땅히 없어서 모두 id라는 인조 필드를 만들고 기본키로 설정했

읽기전용 계정을 통해 직접 접근하는 DB에 대해 수정하는 실수를 막기 위함이다.CREATE USER readOnlyUser1 IDENTIFIED BY '1234';GRANT SELECT ON \*.\* TO readOnlyUser1;SELECT \* FROM mysql

기본 개념은 각설하고 인덱싱을 어떻게 처리하는 과정을 담았습니다.적용전 엔티티데이터베이스를 설계할때 애플리케이션 내부용 키로는 increment pk를, 외부에 공개할 키로는 uuid를 사용하는 것을 권장한다.위의 코드는 appId가 노출 되는 경우 재발급까지 고려해서

바로 실행할 경우

실제 사용중인 오늘을 표현하는 다양한 쿼리문을 기록.DATE로 타입캐스트애트리뷰트가 DATETIME라면 00:00:00 추가추가적으로 시차까지 적용하여 사용중이다.상황에 맞춰 적절하게 사용하면된다.

MSSQL에서 복합 인덱스 만들때예를 들어,라는 쿼리문을 자주 사용하고 해당 조건문들에 대해서 PK, UK가 아니라고 가정했을때Index (a, b, c) 와 Index (a, b) 가 적절할까?결론부터 말하자면 전자인 Index (a, b, c) 를 사용하는 것이 정

예시의 쿼리는 리팩토링 전 테이블 설계입니다.데이터 집계할때는 단순한 집계 함수를 사용하는 것보다는 Merge Join을 사용하는 것이 데이터가 커질수록 성능에 좋다.개선 전 쿼리개선 후 쿼리개선 전후로 30% 상승한 것을 볼 수 있다.PK를 이용한 Merge Join

▎ IDENTITY 컬럼 재설계와 스키마 분리를 서비스 중단 없이 처리하는 Ghost Table 패턴 배경 — 왜 이 전략이 필요한가 운영 중인 items 테이블에 구조적 변경이 필요했다. 문제 1. 하나의 테이블에 성격이 다른 데이터(일반 아이템 / 가챠 아이템

써로게이트 키(surrogate key)는 데이터 자체의 의미와 무관하게 식별 목적으로만 부여하는 인위적인 기본키다.교과서에서는 다음 세 가지 경우에 써로게이트 키가 필요하다고 말한다.입력 데이터 중 기본키가 될 만한 항목이 없는 경우주문 상세, 로그, 이벤트 이력처럼

LIMIT / OFFSET은 쓰기 쉽지만, 데이터가 쌓이면 뒤 페이지부터 조용히 무너진다. 왜 그런지를 실행 계획 수준에서 살펴보고, Keyset 기반으로 어떻게 대체하는지 다룬다.어느 시점에 목록 조회에 페이지네이션을 구현해야 한다. 대부분 가장 익숙한 방법을 선택한