홈 › SQL 중급 › 11 / 11

뷰·시퀀스·자동 증가

VIEW, SEQUENCE, IDENTITY, AUTO_INCREMENT
섹션 6진행 0 / 11

2. 핵심 원리

2.1 뷰는 저장된 쿼리다

뷰는 데이터를 따로 저장하지 않고 SELECT 문을 이름 붙여 저장해둔 것입니다. 뷰를 조회하면 그 순간 저장된 쿼리가 실행되어 원본 테이블의 최신 데이터를 그대로 돌려줍니다.

핵심

뷰는 데이터의 복사본이 아니라 쿼리의 별명입니다. 원본 테이블이 바뀌면 뷰를 다시 만들 필요 없이 조회 결과도 즉시 바뀝니다. 데이터를 실제로 미리 계산해 저장해두는 "머티리얼라이즈드 뷰"(Oracle MATERIALIZED VIEW, MSSQL 인덱싱된 뷰, MySQL 은 없음)는 이와 달리 별도의 저장 공간을 씁니다(이름만 소개).

2.2 CREATE VIEW·CREATE OR REPLACE VIEW

세 DB 모두 CREATE VIEW 이름 AS SELECT ... 로 뷰를 만듭니다. 이미 있는 뷰의 정의를 바꿀 때는 CREATE OR REPLACE VIEW 를 쓰면 DROP 후 다시 만드는 두 단계를 한 번에 처리합니다.

DB CREATE OR REPLACE VIEW
Oracle·Tibero 지원
MySQL 지원
MSSQL 2016 SP1 부터 CREATE OR ALTER VIEW, 그 전에는 ALTER VIEW

2.3 뷰를 통한 UPDATE·INSERT 가 가능한 조건

실제 DB(Oracle·MySQL·MSSQL)는 뷰가 다음 조건을 만족하면 그 뷰에 UPDATE·INSERT·DELETE 를 쓸 수 있게 해줍니다. 조건에서 벗어나면 DB 가 DML 을 거부합니다.

  • 뷰의 SELECT 가 테이블 하나만 참조한다(조인이 없다).
  • GROUP BY·집계 함수·DISTINCT 가 없다.
  • 뷰의 컬럼과 원본 테이블의 컬럼이 1:1로 대응한다.
주의

H2 2.3.232 는 이 조건을 만족하는 단순한 단일 테이블 뷰라도 뷰를 통한 UPDATE·INSERT 자체를 지원하지 않습니다(Feature not supported: "TableView.removeRow"). 실제 Oracle·MySQL·MSSQL 은 조건을 만족하는 뷰라면 DML 을 허용하므로, 이 레슨의 -- @error 시연은 "H2 미지원, 문법 검토만"으로 읽어야 합니다.

2.4 WITH CHECK OPTION

WITH CHECK OPTION 을 뷰 정의에 붙이면, 그 뷰를 통한 INSERT·UPDATE 가 뷰의 WHERE 조건을 벗어나는 행을 만들지 못하게 막습니다. 예를 들어 WHERE dept = '개발' 인 뷰에 이 옵션을 붙이면, 그 뷰로 다른 부서 행을 넣거나 부서를 바꾸는 수정을 DB 가 거부합니다.

주의

Oracle·MySQL·MSSQL 은 모두 WITH CHECK OPTION 을 지원하지만, H2 2.3.232 는 CREATE VIEW 문법 자체에서 이 옵션을 받아들이지 않아 구문 오류가 납니다. H2 미지원, 문법 검토만입니다.

2.5 SEQUENCE: 번호를 미리 채번하는 객체

SEQUENCE 는 테이블과 독립된 채번 전용 객체입니다. START WITH 로 시작 값, INCREMENT BY 로 증가 폭을 정하고, CACHE 로 DB 가 메모리에 미리 확보해둘 번호 개수를 정합니다. 표준 SQL 은 NEXT VALUE FOR 시퀀스 로 다음 번호를 뽑습니다.

2.6 IDENTITY 컬럼: 표준 자동 증가

표준 SQL 은 GENERATED ALWAYS AS IDENTITY·GENERATED BY DEFAULT AS IDENTITY 로 컬럼 자체를 자동 증가로 선언합니다. ALWAYS 는 값을 직접 넣을 수 없게 막고, BY DEFAULT 는 생략하면 자동 채번하되 직접 지정도 허용합니다. Oracle 은 12c 부터 이 표준 IDENTITY 컬럼을 지원합니다.

2.7 채번 값의 구멍(gap)

시퀀스와 IDENTITY 는 한 번 뽑은 번호를 절대 되돌리지 않습니다. INSERT 가 실패하거나 ROLLBACK 되어도 이미 뽑은 번호는 소모된 채로 남아, 다음 번호와의 사이에 구멍이 생깁니다.

CACHE 로 미리 확보해둔 번호도 마찬가지입니다. DB 가 재시작되면 메모리에 있던 캐시분(아직 안 쓴 번호)은 버려지고 다음 채번은 그 뒤 번호부터 다시 시작해, 재시작 때마다 캐시 크기만큼 구멍이 생길 수 있습니다.

주의

세금계산서 번호처럼 "빈 번호 없이 1씩 연속"이어야 하는 값은 시퀀스나 IDENTITY 로 보장할 수 없습니다. 롤백·캐시 모두 구멍을 만들기 때문입니다. 이런 요구에는 별도의 채번 테이블과 락을 쓰는 전략이 필요하며, 두 방식의 장단점은 실무 06 에서 더 다룹니다.