SQL 뷰(view)

users 테이블

user_id	username	email
1	Alice	alice@example.com
2	Bob	bob@example.com
3	Charlie	charlie@example.com

tasks 테이블

task_id	user_id	status
1	1	완료
2	1	진행 중
3	2	완료
4	2	완료
5	3	진행 중

user_task_summary View (결과)

user_id	username	completed_tasks
1	Alice	1
2	Bob	2
3	Charlie	0

• users 테이블: 사용자 정보(아이디, 이름, 이메일) 포함.
• tasks 테이블: 작업 정보(아이디, 사용자 아이디, 상태) 포함.
• user_task_summary View: users와 tasks를 합친 것으로, 각 사용자의 완료 작업 수 표시.

CREATE VIEW user_task_summary AS
SELECT
    u.user_id,
    u.username,
    COUNT(t.task_id) AS completed_tasks
FROM users u
LEFT JOIN tasks t ON u.user_id = t.user_id AND t.status = '완료'
GROUP BY u.user_id, u.username;

이론 설명

데이터베이스의 View는 가상 테이블이며, 실제 테이블의 데이터를 조합해서 만들어진다. View의 주된 목적은:

1. 복잡한 쿼리의 단순화: View를 통해 복잡한 데이터에 쉽게 접근할 수 있다.
2. 데이터 추상화와 은닉: 데이터의 출처와 처리 과정을 숨기고, 데이터 구조의 변경이 애플리케이션에 미치는 영향을 줄인다.
3. 보안 강화: View를 사용해 특정 데이터만을 노출시켜 데이터 접근을 제어하고 중요한 정보를 보호할 수 있다.
4. 성능 최적화: 데이터베이스는 View의 쿼리를 최적화하고 물리적 뷰를 사용해 쿼리 결과를 캐싱함으로써 조회 성능을 향상시킬 수 있다.

실제 사용 예시

배경

프로젝트 관리 도구를 만들고 있다고 가정해보자. 이 도구에서는 프로젝트 구성원이 작업을 등록하고 상태를 '완료' 또는 '진행 중'으로 표시할 수 있다. 프로젝트 대시보드에서는 각 구성원이 완료한 작업의 수를 요약 정보로 보여줘야 한다.

구현

• users 테이블: 모든 구성원의 정보를 저장한다.
• tasks 테이블: 각 작업의 정보 및 상태를 저장한다.

View 생성: user_task_summary View는 users 테이블과 tasks 테이블을 결합하여 각 사용자별로 완료한 작업의 수를 집계한다.

CREATE VIEW user_task_summary AS
SELECT
    u.user_id,
    u.username,
    COUNT(t.task_id) AS completed_tasks
FROM users u
LEFT JOIN tasks t ON u.user_id = t.user_id AND t.status = '완료'
GROUP BY u.user_id, u.username;

현업 적용: 프로젝트 대시보드에서는 이 View를 통해 간단히 각 사용자별 완료 작업의 수를 조회할 수 있다. 개발자는 복잡한 조인 및 집계 쿼리를 직접 작성할 필요 없이, SELECT * FROM user_task_summary;와 같은 간단한 쿼리로 정보를 얻을 수 있다.

View 사용의 장점은:

• 개발 효율성: 복잡한 쿼리를 여러 번 작성하고 관리하는 대신, 한 번의 View 정의로 재사용할 수 있다.
• 유지보수 용이성: 데이터 구조가 변경되어도 View의 정의를 갱신해 애플리케이션 코드의 변경을 최소화할 수 있다.

애플리케이션에서 직접 쿼리를 실행하는 방식과 데이터베이스에서 View를 사용하는 방식은 각각 장단점이 있으며, 사용 사례에 따라 적절한 방식을 선택할 수 있다. 여기서는 두 방식의 주요 차이점을 설명한다.

애플리케이션에서 직접 쿼리 실행

장점

1. 유연성: 애플리케이션 로직에 따라 쿼리를 동적으로 조정하고, 다양한 조건에 따라 데이터를 필터링할 수 있다.
2. 비즈니스 로직 통합: 데이터 조회 로직을 애플리

케이션 코드와 통합해, 복잡한 데이터 처리를 쉽게 구현할 수 있다.

단점

1. 복잡성과 오류 가능성: 복잡한 조인이나 조건을 애플리케이션 코드에서 처리하면 코드가 복잡해지고 오류가 발생할 수 있다.
2. 성능 고려: 애플리케이션에서 데이터를 처리할 때 데이터베이스와 애플리케이션 서버 간의 네트워크 비용과 서버의 리소스 사용량을 고려해야 하며, 이는 성능에 영향을 줄 수 있다.

데이터베이스에서 View 사용

장점

1. 복잡한 쿼리의 단순화: View를 사용하면 데이터베이스에서 복잡한 쿼리를 미리 정의하고, 애플리케이션에서는 단순한 SELECT 쿼리로 필요한 정보에 접근할 수 있다.
2. 데이터 추상화와 보안: View는 데이터의 구조와 복잡한 쿼리 로직을 숨길 수 있으며, 특정 데이터만을 노출시켜 데이터 접근을 제어할 수 있다.
3. 성능 최적화: 데이터베이스는 View의 쿼리를 최적화하고, 물리적 뷰를 사용해 쿼리 결과를 사전에 계산하고 저장함으로써 성능을 향상시킬 수 있다.

단점

1. 유연성 제한: View는 미리 정의된 쿼리 구조를 가지므로, 동적인 쿼리 요구사항이나 애플리케이션 로직에 따른 즉각적인 조정이 어렵다.
2. 데이터베이스 의존성: View를 사용하는 방식은 특정 데이터베이스 시스템의 기능에 의존할 수 있으며, 데이터베이스 간의 호환성에 제약을 받을 수 있다.

결론

애플리케이션에서 직접 쿼리를 실행하는 방식은 유연성을 제공하지만 복잡성과 성능 고려사항이 있다. 반면, 데이터베이스에서 View를 사용하는 방식은 복잡한 쿼리를 단순화하고 데이터를 추상화하며 성능을 최적화하는 등의 이점을 제공하지만, 유연성과 데이터베이스 의존성의 제약이 있을 수 있다.