데이터베이스에 GUID가 기본 키로 있습니다. 이는 여러 시스템에서 고유성을 적용하기 위해 수행되었습니다.SQL 계산 된 필드 효율성
것은 약간 우호적 내가 계산 필드를 추가 한 테이블을 만들려면 (그래 내가 오버 헤드 다른 옵션이 있지만, 회사의 선택이있는 테이블 당 행 당 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
내가 이러한 업이 기본 키에 대해 항상 보이는 것을 지적한다/클러스터 색인은 개별적으로 최대한 빨리 만들 수 있습니다.
이제는 문제를 추적 할 때 많은 이점이 있지만 큰 테이블을 쿼리 할 때 주 사용 효율 (계산 된 필드가 쿼리되지 않으므로 아무런 영향도주지 않음)에 아무런 영향을 미치지 않지만, 조회를 수행하는 동안. 나는 찾고있는 여분의 데이터를 희생하고 싶지 않고 테이블에 직접 저장하고 싶지 않습니다 (데이터 낭비와 유지 관리가 필요합니다). 나는 각 테이블에 대한 뷰를 빌드하는 것을 고려해 왔지만 과장된 것 같아서 노력을 두 배로 늘릴 필요가 없습니다.
저는 이처럼 일하는 사람이 유일한 사람이 아니라고 확신합니다. 누군가이 일을보다 효율적으로 수행 할 수 있는지 알고 싶습니다. 이 필드는 데이터베이스를 직접보고있는 사람들 만 사용하며 모든 저장 프로 시저 등은 모두 인덱싱 된 링크 등으로 모두 코드화되므로 기본 실행 효율성은 디버깅 중일뿐입니다. 큰 문제는 아니지만, 더 좋은 해결책이 있다면 듣고 싶습니다.
미리 감사드립니다.
그래서 개발자가 쉽게 사용할 수 있도록 스칼라 함수를 사용하여 계산 된 열을 테이블에 추가합니까? 그들은 조인을 작성하는 법을 배워야하지 않습니까? 그 조인을 타이핑하는 것이 당신이하려고하는 것보다 적은 노력 일 것입니다. –
솔직하게 다른 사람들만큼 여기에서 데이터를 추적합니다. 더 직관적 인 것이 더 낫습니다. 데이터에 시간을 보내는 모든 사람들 (그리고 한 소녀)은 조인을 작성할 수 있으며, 필요할 때마다 반복해서 반복해야합니다. 차라리 한 번 해보고 다시하지 않아도됩니다. –
또는 조인을 수행하는보기를 작성하십시오. 스. 라 UDF에서 이것을 랩핑하면 성능이 매우 빨리 저하됩니다. 모든 조회가 RBAR 중첩 루프를 사용하고 스칼라 UDF와 관련된 여러 가지 문제점을 갖도록합니다. –