티스토리 뷰
SQL에서 DDL과 DML의 차이점을 설명하고, 각각의 대표적인 명령어들의 용도를 설명하세요.
DDL (Data Definition Language)
데이터베이스의 뼈대(구조)를 결정하는 명령어
대표적인 명령어들과 용도
CREATE 생성 : 새로운 테이블이나 데이터베이스를 만듦
ALTER 수정 : 기존에 만든 테이블의 구조를 바꿈 (컬럼 추가, 타입 변경 등)
DROP 삭제 : 테이블이나 데이터베이스를 삭제
TRUNCATE 초기화 : 테이블의 구조는 남겨두고 테이블 내의 데이터만 삭제
--CREATE
CREATE TABLE products (
id SERIAL PRIMARY KEY,
name VARCHAR(100),
price NUMERIC
);
--ALTER
ALTER TABLE products ADD COLUMN stock INTEGER;
--DROP
DROP TABLE products;
--TRUNCATE
TRUNCATE TABLE products;
DML (Data Manipulation Language)
실제 테이블 안에 들어있는 데이터를 관리할 때 사용
대표적인 명령어들과 용도
INSERT 삽입 : 테이블에 새로운 데이터를 집어넣음
UPDATE 수정 : 기존 데이터 수정
DELETE 삭제 : 기존 데이터 삭제
--INSERT
INSERT INTO users (name, email) VALUES ('김개발', 'kim@example.com');
--UPDATE
UPDATE users SET email = 'new@example.com' WHERE id = 1;
--DELETE
DELETE FROM users WHERE name = '홍길동';
두줄 요약
DDL(정의어) 테이블 자체를 만들거나 구조를 바꾸는 것
DML(조작어) 데이터를 넣고 빼고 수정하는 것
역정규화가 필요한 상황과 적용 시 고려해야 할 사항, 그리고 역정규화를 적용할 때의 장단점을 설명해주세요.
역정규화(Denormalization)
정규화된 데이터 모델에서 일부 구조를 의도적으로 통합하거나 중복시켜 성능과 응답 시간을 개선하는 설계 기법
쉽게 말해 너무 잘게 쪼개진 테이블들을 다시 합치거나 중복 데이터를 허용하는 것
역정규화가 필요한 상황
JOIN이 너무 많을 때: 데이터를 하나 가져오는데 5~6개의 테이블을 JOIN해야 해서 속도가 너무 느려질 때
상황: 쇼핑몰에서 '주문 상세 페이지'를 보여줘야 할 때
원래 구조 (정규화): 주문 테이블 + 회원 테이블 + 상품 테이블 + 배송지 테이블 + 쿠폰 테이블... (모두 JOIN)
역정규화 예시: [주문 테이블] 안에 아예 [주문자 이름]과 [상품명]을 직접 써버리는 것
효과: 주문 내역을 부를 때 다른 테이블로 갈 필요 없이 한 번에 읽어오면 끝
조회(SELECT) 비중이 압도적일 때: 데이터 수정은 가끔 일어나는데, 조회는 수천 번 일어나는 서비스일 때
상황: SNS의 게시글 리스트.
원래 구조 (정규화): 게시글을 볼 때마다 작성자의 [프로필 사진]과 [닉네임]을 얻으러 '회원 테이블'에 매번 접근해야 함
역정규화 예시: [게시글 테이블] 안에 작성자의 [닉네임]과 [프로필 이미지 URL]을 미리 복사해둠
효과: 수백만 명의 사용자가 피드를 새로고침할 때마다 회원 테이블에 달려갈 필요가 없음
통계/집계 계산이 복잡할 때: 매번 실시간으로 합계(SUM)나 평균(AVG)을 계산하기엔 양이 너무 많을 때 (미리 계산된 값을 컬럼에 저장)
상황: 블로그 메인 화면에 표시되는 '전체 방문자 수'나 '댓글 개수'.
원래 구조 (정규화): 페이지를 열 때마다 SELECT COUNT(*)로 수만 개의 댓글을 매번 새로 셈
역정규화 예시: [게시글 테이블]에 [total_comments]라는 칸을 만들고, 댓글이 달릴 때마다 +1씩 미리 더해둠
효과: 조회할 때는 계산할 필요 없이 숫자 하나만 읽으면 되니 속도가 빠름
고려해야 할 사항
데이터 무결성 보장 대책: 데이터가 중복되므로 한 곳이 수정될 때 다른 곳도 같이 수정되도록 트리거(Trigger)나 애플리케이션 로직을 튼튼하게 짜야함
상황: 사용자가 닉네임을 '길동이'에서 '홍길동'으로 바꿨을 때
예시: 트리거(Trigger): DB 자체에 "회원 테이블의 이름이 바뀌면, 게시글 테이블에 복사된 이름들도 다 같이 바꿔"라는 자동 명령을 심어두는 것
로직: 개발자가 코딩할 때 updateNickname() 함수 안에 회원 테이블 수정 코드와 게시글 테이블 수정 코드를 동시에 넣어두는 것
리스크: 이걸 깜빡하면? 게시글에는 옛날 이름이 나오고, 프로필에는 새 이름이 나오는 데이터 불일치가 발생
읽기 vs 쓰기 비율: 쓰기(INSERT/UPDATE)가 빈번한 시스템에서 역정규화를 하면 오히려 성능이 더 떨어짐
상황: 실시간 주식 시세 시스템이나 초단위로 바뀌는 예약 시스템
예시: 1초에 데이터가 100번 업데이트되는데, 조회가 10번뿐이라면?
이유: 업데이트할 때마다 중복된 모든 테이블을 다 찾아가서 고쳐야 하므로 DB가 과부하
결론: 조회(Read)가 쓰기(Write)보다 최소 10배 이상 많을 때 역정규화가 빛을 발함
대안 검토: 인덱스(Index) 최적화, 뷰(View), 캐시(Redis 등) 사용으로 해결할 수 없는지 먼저 확인해야 함
인덱스(Index) 최적화: 테이블을 합치지 않아도, 목차(인덱스)만 잘 만들면 JOIN 속도가 비약적으로 빨라질 수 있음
캐시(Redis 등): DB 구조를 건드리는 대신, 자주 조회되는 데이터를 메모리(Redis)에 따로 저장해두고 꺼내 쓰는 방식
예시: 인기 게시글 10개 같은 건 굳이 DB 역정규화를 안 해도, 캐시에 담아두면 DB까지 갈 필요도 없이 엄청나게 빠름
역정규화의 장단점
장점
JOIN 제거 → 쿼리 속도 향상
집계 연산 제거 → 응답 시간 단축
테이블 수 감소 → 모델 단순화
CPU, 메모리 사용량이 줄어듦
단점
데이터 중복 발생
갱신 시 동기화 로직 필요 → 복잡한 트리거 또는 서비스 레이어 처리
중복 저장으로 인한 필요 데이터 공간이 늘어나므로 유지보수 비용 증가
두줄 요약
정규화는 중복을 없애고, 역정규화는 성능을 위해 중복을 허용한다.
결국 역정규화는 '데이터의 완결성'과 '사용자의 체감 속도' 사이에서 최적의 균형점을 찾아가는 기술적 선택