뷰
View
저장된 쿼리를 테이블처럼 사용. 가상 테이블.
View
저장된 쿼리를 테이블처럼 사용. 가상 테이블.
뷰(View)는 SQL 쿼리를 저장해두고 가상 테이블처럼 사용할 수 있는 데이터베이스 객체입니다. 실제 데이터를 저장하지 않고, 조회 시점에 정의된 쿼리를 실행하여 결과를 반환합니다.
뷰의 주요 장점: 복잡한 쿼리 단순화(자주 사용하는 조인/집계를 뷰로 정의), 보안 강화(민감한 컬럼 숨기기), 데이터 추상화(테이블 구조 변경 시 영향 최소화), 일관성 유지(비즈니스 로직 중앙 관리).
업데이트 가능 뷰(Updatable View)는 특정 조건(단일 테이블 기반, 집계 없음 등)을 만족하면 INSERT/UPDATE/DELETE가 가능합니다.
-- 기본 뷰 생성
CREATE VIEW active_customers AS
SELECT id, name, email, created_at
FROM customers
WHERE status = 'active' AND deleted_at IS NULL;
-- 뷰 사용 (테이블처럼)
SELECT * FROM active_customers WHERE created_at > '2024-01-01';
-- 복잡한 조인을 뷰로 캡슐화
CREATE VIEW order_details AS
SELECT
o.id AS order_id,
c.name AS customer_name,
p.name AS product_name,
oi.quantity,
oi.price,
o.created_at
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id;
-- 보안용 뷰: 민감 정보 제외
CREATE VIEW public_users AS
SELECT id, username, department
FROM users; -- password, salary 등 제외
-- 업데이트 가능 뷰
CREATE VIEW pending_orders AS
SELECT * FROM orders WHERE status = 'pending';
-- 뷰를 통한 업데이트 (기반 테이블에 반영)
UPDATE pending_orders SET status = 'confirmed' WHERE id = 123;
주니어 개발자: "이 5개 테이블 조인 쿼리가 여러 곳에서 복사되어 있어요."
시니어 개발자: "뷰로 만들어서 중앙 관리하면 좋겠네요. 수정할 때도 한 곳만 고치면 되고요."
주니어 개발자: "뷰가 성능에 영향을 주나요?"
시니어 개발자: "뷰 자체는 쿼리를 저장하는 거라 매번 실행돼요. 성능 이슈가 있으면 머티리얼라이즈드 뷰 검토해보세요."
면접관: "뷰를 사용하는 이유와 제한사항을 설명해주세요."
지원자: "뷰는 복잡한 쿼리 재사용, 보안(컬럼 숨김), 테이블 구조 추상화에 사용합니다. 제한사항은 조회 시 매번 쿼리 실행으로 성능 오버헤드가 있고, 집계나 조인이 포함된 뷰는 UPDATE가 불가능합니다."
면접관: "실제 사용 경험을 말씀해주세요."
지원자: "API 권한별로 다른 뷰를 제공해서 데이터 접근을 제어했고, 리포팅용 복잡 쿼리를 뷰로 정의해 분석팀에 제공했습니다."
리뷰어: "이 뷰 안에 서브쿼리가 또 있고, 그 안에 또 뷰를 참조하네요."
개발자: "기존 뷰를 재활용하려고요."
리뷰어: "뷰가 뷰를 참조하면 디버깅이 어렵고 성능 예측도 힘들어요. 실행 계획 확인해보고, 필요하면 단일 쿼리로 풀어쓰거나 머티리얼라이즈드 뷰로 전환하세요."
개발자: "실행 계획 보니 중첩 때문에 비효율적이네요. 정리하겠습니다."