[DB/SQL] 뷰(View) 그리고 프로시저(Procedure) 개념
뷰(View)와 프로시저(Procedure) 개념
테이블(Table)이나 쿼리(Query)는 익숙하지만,
뷰(View)나 프로시저(Procedure)는
상대적으로 생소하게 느껴져서 이번 기회에 개념을 정리해보았습니다.
제가 현재 다니고 있는 회사에서는 뷰와 프로시저를 자주 사용하진 않지만,
실제로 사용하는 기업도 많기 때문에 개념만이라도 알고 있으면
실무에 도움이 될 것 같다는 생각이 들어 해당 포스팅을 작성하게 되었습니다 :)
1. 뷰(VIEW)란?
뷰는 데이터베이스에 존재하는 일종의 가상테이블 입니다.
가상테이블이란? 이름 그대로 실제 데이터를 가지고 있지 않은 테이블을 의미합니다.
말 그대로 실제 데이터를 저장하지 않고,
특정 SQL 쿼리문을 저장하여 데이터를 조회만 할 수 있는 테이블 형태 입니다.
VIEW를 통해 데이터를 관리 할 수 있습니다.
VIEW는 데이터가 없고 SQL만 저장하고
TABLE은 실질적인 데이터가 있다.
뷰(VIEW)의 사용목적
- 복잡한 쿼리문을 간단하게 재사용할 수 있습니다. (데이터 조회 용이)
- 중복되는 쿼리문을 하나의 뷰로 관리할 수 있습니다.
- 사용자에게 보여줄 컬럼을 제한하여 보안성을 높일 수 있습니다. (보안성)
뷰(VIEW)의 단점 및 제약사항
- 삽입(INSERT), 갱신(UPDATE), 삭제(DELETE) 연산에 제약이 있습니다.
특히 복합 뷰의 경우에는 이러한 조작이 불가능합니다.
- 단순 뷰 vs 복합 뷰
단순 뷰: 하나의 기본 테이블을 기반으로 정의
복합 뷰: 여러 테이블을 조합하거나 GROUP BY, UNION, 함수 등을 사용하는 뷰
- 뷰는 인덱스를 만들 수 없으며, 다른 뷰를 포함하는 뷰의 경우, 연관된 뷰가 삭제되면 함께 삭제됩니다.
- 또한, 한 번 정의된 뷰는 수정이 불가능하며, 수정하려면 삭제 후 재생성이 필요합니다.
테이블(TABLE)이 아닌 뷰(VIEW)를 사용하는 이유
데이터의 보안과 사용자의 편리함 때문이다.
원본 테이블에 직접적으로 접근하지 않고,
뷰를 통해 필요한 데이터만 보여줄 수 있기 때문에 보안적으로도 안전하며,
자주 사용하는 복잡한 쿼리를 매번 작성할 필요 없이 간편하게 조회할 수 있습니다.
💡 실무에서의 경험
대부분은 API 방식으로 연동하지만, 일부 업체는 DB 연동 방식을 사용하고 있었고,
이 경우 원본 테이블이 아닌 VIEW만 접근 가능하도록 제공되고 있었습니다.
2. 프로시저(Procedure) 란?
프로시저는 SQL문장을 일련의 로직으로 묶어서, 하나의 함수처럼 실행할 수 있는 쿼리 집합입니다.
주로 SQL Server/Oracle/MySQL 등에서 사용됩니다.
DBMS에 저장되는 영구 저장 모듈 형태로, 자주 사용하는 SQL 로직을 절차적으로 정의해 둘 수 있습니다.
프로시저의 장점
- 네트워크 부하 감소: 여러 SQL 문을 하나의 요청으로 처리할 수 있어 효율적입니다.
- 실행 속도 향상: 사전 컴파일이 되어 있어 구문 분석 시간이 줄어듭니다.
- 참조 무결성 유지 가능: 트리거와 함께 사용 시, 데이터 무결성 유지를 자동화할 수 있습니다.
- 유지보수 용이: Java 등의 외부 언어와 쿼리를 분리할 수 있고, 프로시저만 교체해도 기능을 수정할 수 있어 유지보수에 유리합니다.
프로시저의 단점
- 디버깅이 어렵습니다.
- DB 서버 확장에 제약이 있습니다.
- SQL/PSM 표준과 호환성이 낮은 경우가 많아, 다른 DBMS로 이식이 어렵습니다.
- 비즈니스 로직을 프로시저에 넣을 경우 사양 변경 시 외부 응용 프로그램과 함께 프로시저도 수정해야 하므로
유지보수 시 실수나 장애 가능성이 존재합니다.
뷰와 프로시저는 평소 자주 접하지 않더라도,
다른 회사나 프로젝트에서 얼마든지 등장할 수 있는 개념입니다.
특히 외부와의 연동, 복잡한 쿼리의 재사용, 보안이 중요한 환경에서
매우 유용하게 쓰일 수 있기 때문에
기본 개념만이라도 숙지해두면 실무에서 분명 도움이 될 것입니다 !
😎