SQL 계산 된 필드 효율성

Question

데이터베이스에 GUID가 기본 키로 있습니다. 이는 여러 시스템에서 고유성을 적용하기 위해 수행되었습니다.

것은 약간 우호적 내가 계산 필드를 추가 한 테이블을 만들려면 (그래 내가 오버 헤드 다른 옵션이 있지만, 회사의 선택이있는 테이블 당 행 당 16 바이트) 알고, 그래서 당신은 같은 선택을 할 경우

SELECT * FROM Products 

외래 키를 사용하여 열을 가져올뿐만 아니라 이와 관련된 필드도 가져옵니다.

CompanyGUID (저장 필드), 회사 명 (계산 필드) 계산 된 필드와 같은 스칼라 함수를 통해 실행

:

이

CREATE FUNCTION [mySchema].[udf_CompanyNameFromGUID] (@GUID UNIQUEIDENTIFIER) 
RETURNS NVARCHAR(MAX) 
AS 
    BEGIN 
     DECLARE @Return NVARCHAR(MAX) 
     SELECT @Return = CompanyName 
     FROM mySchema.Companies 
     WHERE CompanyGUID = @GUID 
     RETURN @Return 
    END 

내가 이러한 업이 기본 키에 대해 항상 보이는 것을 지적한다/클러스터 색인은 개별적으로 최대한 빨리 만들 수 있습니다.

이제는 문제를 추적 할 때 많은 이점이 있지만 큰 테이블을 쿼리 할 때 주 사용 효율 (계산 된 필드가 쿼리되지 않으므로 아무런 영향도주지 않음)에 아무런 영향을 미치지 않지만, 조회를 수행하는 동안. 나는 찾고있는 여분의 데이터를 희생하고 싶지 않고 테이블에 직접 저장하고 싶지 않습니다 (데이터 낭비와 유지 관리가 필요합니다). 나는 각 테이블에 대한 뷰를 빌드하는 것을 고려해 왔지만 과장된 것 같아서 노력을 두 배로 늘릴 필요가 없습니다.

저는 이처럼 일하는 사람이 유일한 사람이 아니라고 확신합니다. 누군가이 일을보다 효율적으로 수행 할 수 있는지 알고 싶습니다. 이 필드는 데이터베이스를 직접보고있는 사람들 만 사용하며 모든 저장 프로 시저 등은 모두 인덱싱 된 링크 등으로 모두 코드화되므로 기본 실행 효율성은 디버깅 중일뿐입니다. 큰 문제는 아니지만, 더 좋은 해결책이 있다면 듣고 싶습니다.

미리 감사드립니다.

Answer 1

내 추천 :

1. 열 companyGUID를 들어, 생성하고 NEWSEQUENTIALID 대신 NEWID을 사용할 수 있습니다, 그것은 단편화를 줄일 수 있습니다. 색인 성능을 향상시킬 수 있습니다.
2. PERSISTED 옵션을 추가하여 CompanyName 열을 유지할 수 있습니다.

Answer 2

주된 성능 문제는 조회로 인한 것이 아니며, SCALAR FUNCTION 사용으로 인한 것입니다.

스칼라 함수는 모든 행에 대해 호출되며 자체적으로는 아니지만 성능에 큰 영향을 미치는 행 수에 대해 곱합니다. 당신이보기를 사용하면 확장됩니다 단지 코드의대로 추가 공간이 필요하지 않습니다, 그리고 내부보기 만 mySchema.Companies와 테이블을 가입 : view 수 있음

는 귀하의 경우 솔루션입니다

을

create view dbo.MyView as 
select * -- put here your columns of interest including CompanyName 
from dbo.YourTable 
    join mySchema.Companies 
     on CompanyGUID = @GUID;