답변.

계산 열은 테이블의 다른 열을 기반으로 자동으로 값이 생성되는 열입니다. 이 개념은 사용자들이 각 쿼리에서 수식을 반복하지 않도록 일반적인 계산 결과에 대한 접근을 단순화하기 위해 등장했습니다. 계산 열은 가상(값이 매 선택 시 계산됨) 또는 물리적(데이터가 업데이트될 때 실제로 저장됨)으로 선언할 수 있습니다.

문제는 모든 표현식이 테이블 수준에서 계산 가능하지 않다는 것입니다(함수 유형에 대한 제한이 있음) 그리고 파생 데이터를 물리적으로 저장하는 것은 공간을 차지하고 UPDATE 시 최신 상태를 유지해야 한다는 점입니다.

해결책: 가능한 경우 DDL 수준에서 계산 열을 선언하거나 저장이 필요한 경우 트리거/프로시저를 통해 업데이트 논리를 구현합니다.

코드 예시 (MS SQL Server):

ALTER TABLE orders ADD total_sum AS (quantity * price); -- 가상
ALTER TABLE orders ADD total_sum_persisted AS (quantity * price) PERSISTED; -- 물리적

주요 특징:

가상 열은 중복성을 줄이지만 조회 속도를 떨어뜨립니다.
물리적 열은 자동으로 업데이트되지만 공간과 자원을 소모합니다.
일부 표현식은 사용이 금지되어 있습니다: 계산 열에서 복제할 수 없는 함수나 서브쿼리를 사용할 수 없습니다.

함정 질문.

계산 열에 인덱스를 만들 수 있습니까?

열이 PERSISTED(물리적으로 저장됨)로 선언된 경우 인덱스를 만들 수 있습니다. 가상 열의 경우 항상 가능하지 않고 DBMS에 따라 다릅니다.

CREATE INDEX ix_total_sum ON orders (total_sum_persisted);

원본 열이 변경되면 계산 열이 자동으로 업데이트됩니까?

예, 원본 데이터를 삽입/편집할 때 열이 테이블 수준에서 계산 열로 선언된 경우 새로운 값이 자동으로 계산됩니다.

계산 열이 NULL을 참조하면 어떻게 됩니까?

대부분의 DBMS는 적어도 하나의 피연산자가 NULL인 경우 NULL을 반환합니다 — 반드시 COALESCE/ISNULL을 통해 가능한 NULL 값을 처리해야 합니다.

ALTER TABLE orders ADD total_with_discount AS (COALESCE(quantity * price, 0));

일반적인 오류 및 안티 패턴

필요 없는 중복된 파생 값을 저장하여 용적이 증가합니다.
작업을 방해하는 복잡하고 인덱스화할 수 없는 표현식을 사용합니다.
애플리케이션 수준에서 계산을 수행하는 경우 일관되지 않은 업데이트가 발생합니다.

실생활 사례

부정적 사례

데이터베이스에 제품의 총액과 가격이 개별 필드로 저장되고, 별도로 total이 저장됩니다. 제품을 업데이트할 때 total을 최신 상태로 유지하는 것을 잊습니다.

장점:

빠른 읽기

단점:

데이터 불일치, 재계산 시 어려움.

긍정적 사례

최종 합계가 가상 열로 선언되어 있습니다. 항상 정확하며 원본 값과 불일치하지 않습니다.