뷰 만들기

보기는 SQL Server에서 데이터에 액세스하고 표시하는 방법을 간소화합니다. SQL 개발자는 복잡한 쿼리를 캡슐화하고, 보안 경계를 제공하고, 애플리케이션의 요구 사항에 맞는 형식으로 데이터를 제공하는 보기를 만듭니다.

SQL Server의 뷰 이해하기

뷰는 SELECT문을 기반으로 한 가상 테이블입니다. 실제 테이블과 달리 뷰는 데이터 자체를 저장하지 않습니다. 대신 쿼리할 때마다 기본 테이블에서 데이터를 검색합니다.

뷰를 사용하면 애플리케이션 코드에서 절, 계산 및 필터의 JOIN 복잡성을 숨길 수 있습니다. 예를 들어 애플리케이션에 제품 세부 정보가 포함된 고객 주문이 자주 필요한 경우 고객, 주문 및 제품 테이블에서 사용하는 JOIN 보기를 만들 수 있습니다. 그런 다음 애플리케이션은 동일한 복합 JOIN 을 반복적으로 작성하는 대신 단일 보기를 쿼리합니다.

보기는 보안 계층도 제공합니다. 기본 테이블에 대한 액세스를 제한하면서 보기를 통해 사용자에게 특정 열에 대한 액세스 권한을 부여할 수 있습니다. 이 방법을 사용하면 사용자에게 전체 테이블 액세스 권한을 부여하지 않고 필요한 데이터만 노출할 수 있습니다.

기본 보기 만들기

CREATE VIEW 문을 사용하여 SELECT 쿼리로 뷰를 만듭니다. 뷰 정의는 뷰를 쿼리할 때 표시되는 데이터를 결정합니다.

고객 및 주문 정보를 결합한 간단한 보기는 다음과 같습니다.

CREATE VIEW Sales.CustomerOrders
AS
SELECT 
    c.CustomerID,
    c.CustomerName,
    c.Email,
    o.OrderID,
    o.OrderDate,
    o.TotalAmount
FROM Sales.Customers c
INNER JOIN Sales.Orders o ON c.CustomerID = o.CustomerID;

이 뷰를 만든 후에는 테이블처럼 쿼리할 수 있습니다.

SELECT * FROM Sales.CustomerOrders
WHERE CustomerName = 'Contoso Ltd';

뷰는 기본 SELECT 문을 실행하고 단일 테이블에서 나온 것처럼 결과를 반환합니다. 이 간소화를 통해 애플리케이션 코드를 더 깨끗하고 쉽게 유지 관리할 수 있습니다.

계산 열을 사용하여 뷰를 만들 수도 있습니다. 다음 보기에서는 순서를 크기별로 분류하는 열을 추가합니다.

CREATE VIEW Sales.OrderSummary
AS
SELECT 
    OrderID,
    CustomerID,
    OrderDate,
    TotalAmount,
    CASE 
        WHEN TotalAmount < 100 THEN 'Small'
        WHEN TotalAmount < 1000 THEN 'Medium'
        ELSE 'Large'
    END AS OrderSize
FROM Sales.Orders;

이 뷰는 분류 논리를 한 곳에서 처리합니다. OrderSummary에 대한 모든 쿼리는 식을 복제하지 않고 동일한 계산을 CASE 가져옵니다.

디자인 고려 사항 적용

뷰를 디자인할 때 뷰를 사용하고 유지 관리하는 방법을 고려합니다. 잘 디자인된 뷰는 단순성, 성능 및 보안의 균형을 이깁니다.

를 사용하는 SELECT *대신 열 이름을 명시적으로 지정합니다. 명시적 열은 보기를 더 쉽게 유지 관리하고 기본 테이블이 변경되면 예기치 않은 결과를 방지합니다. 다른 사용자가 기본 테이블에 열을 추가하는 경우 뷰 정의는 일관성을 유지합니다.

CREATE VIEW Sales.ActiveCustomers
AS
SELECT 
    CustomerID,
    CustomerName,
    Email,
    Phone
FROM Sales.Customers
WHERE IsActive = 1;

뷰가 데이터 수정을 처리할 때 WITH CHECK OPTION 절을 사용합니다. 이 옵션은 INSERT 및 UPDATE 문이 뷰를 통해 조작될 때, 해당 뷰에 표시되는 행에만 영향을 미치도록 보장합니다.

CREATE VIEW Sales.HighValueOrders
AS
SELECT 
    OrderID,
    CustomerID,
    OrderDate,
    TotalAmount
FROM Sales.Orders
WHERE TotalAmount > 1000
WITH CHECK OPTION;

이 옵션을 사용하면 HighValueOrders 보기를 통해 TotalAmount가 500인 주문을 삽입할 수 없습니다. 새 행이 뷰의 WHERE 조건을 충족하지 않으므로 데이터베이스에서 작업을 거부합니다.

보기 정의는 특정 용도에 초점을 맞췄습니다. 여러 용도로 사용하려고 하는 보기는 종종 최적화하고 이해하기 어려워집니다. 하나의 복잡한 보기를 작성하는 대신 다른 사용 사례에 대해 별도의 보기를 만듭니다.

뷰를 사용하는 시기 결정

특정 특성이 명확한 이점을 제공하는 시나리오에서 뷰는 탁월합니다. 이러한 시나리오를 이해하면 각 상황에 적합한 도구를 선택하는 데 도움이 됩니다.

보기를 사용하여 여러 애플리케이션 또는 사용자가 실행해야 하는 복잡한 쿼리를 간소화합니다. 모든 사용자가 특정 조건으로 5개의 테이블을 조인하는 복잡성을 이해하도록 요구하는 대신 보기를 한 번 만듭니다. 또한 이 중앙 집중화는 논리를 한 곳에서 최적화하거나 수정할 수 있습니다.

데이터 액세스를 열 또는 행 수준에서 제한해야 할 경우에는 보기를 고려하십시오. 뷰는 중요한 정보를 숨기는 동안 역할에 적합한 열만 노출할 수 있습니다. 적절한 사용 권한과 결합하면 뷰를 통해 전체 테이블을 노출하지 않고도 특정 데이터에 대한 액세스 권한을 부여할 수 있습니다.

보기는 다양한 용도로 다양한 형식으로 데이터를 표시하는 데 적합합니다. 기술 세부 정보가 포함된 Products 테이블이 있을 수 있지만 보고 팀에는 계산 필드가 있는 간소화된 버전이 필요합니다. 데이터를 적절하게 변환하고 집계하는 뷰를 만듭니다.

동시에 다른 개체가 더 잘 사용될 때를 인식합니다. 항상 동일한 결과를 반환하는 성능에 중요한 쿼리의 경우 인덱싱된 뷰(구체화된 뷰)는 결과 집합을 물리적으로 저장합니다. 매개 변수를 허용하는 복잡한 계산의 경우 사용자 정의 함수는 더 많은 유연성을 제공합니다. 데이터 수정 논리의 경우 저장 프로시저는 더 나은 제어를 제공합니다.

매개 변수 없이 재사용 가능한 쿼리 논리를 캡슐화해야 하고 데이터를 간소화된 방식으로 표시하려는 경우 뷰가 솔루션입니다. 실제 데이터베이스 구조와 애플리케이션에 필요한 데이터의 논리적 뷰 사이의 간격을 메우고 있습니다.