스칼라 값 함수에 select가 아닌 실행 권한이 필요한 이유는 무엇입니까?

스칼라 값 함수의 경우 사용자에게 선택이 아닌 실행 권한을 부여 해야하는 이유가 궁금합니다.

반면 테이블 값 함수는 선택 권한 또는 db_datareader멤버 자격 으로 만 작동합니다 .

여기에 더 분명한 것은 내 예입니다. 데이터베이스에 대한 읽기 전용 권한이있는 사용자가 필요합니다. 그래서 전화 한 사용자를 만들고 회원을 testUser부여했습니다 db_datareader. 그런 다음이라는 테이블 값 함수를 만들었습니다 fn_InlineTable. 그리고 모두 훌륭합니다. testUser하루 종일이 SQL을 실행

select * from dbo.fn_InlineTable

스칼라 함수가 필요하므로라는 스칼라 함수를 만들었습니다 fn_ScalarTest. testUser이 SQL을 실행할 수 없습니다

Select dbo.fn_ScalarTest(1) 

이해할 수있는 것은 "testUser"권한을 실행하지 않았기 때문 fn_ScalarTest입니다.

내 질문은 :이 링크 /programming/6150888/insert-update-delete-with-function-in-sql-server 에 FUNCTION따라 데이터베이스 상태를 수정하는 작업을 수행하는 데 사용할 수 없습니다 . 그렇다면 스칼라 함수를 실행 권한 대신 동일한 "SELECT"권한과 함께 사용하지 않겠습니까?

내 질문이 이해되기를 바랍니다. 감사합니다.

대부분의 주된 이유는 테이블 반환 함수가 테이블 및 뷰와 마찬가지로 결과 집합을 반환하기 때문입니다. 이는 , 및 의 등을 FROM포함하여 ,JOINAPPLYSELECTUPDATE 및 DELETE쿼리. 그러나 이러한 상황에서는 Scalar UDF를 사용할 수 없습니다.

둘째, EXECUTE스칼라 UDF도 가능합니다. 이 구문은 입력 매개 변수에 지정된 기본값이있을 때 매우 유용합니다. 예를 들어 다음 UDF를 사용하십시오.

CREATE FUNCTION dbo.OptionalParameterTest (@Param1 INT = 1, @Param2 INT = 2)
RETURNS INT
AS
BEGIN
    RETURN @Param1 + @Param2;
END;

입력 매개 변수를 "선택적"으로 취급 DEFAULT하려면 서명이 고정 되어 있으므로 키워드를 함수처럼 호출 할 때 키워드 를 전달해야합니다 .

DECLARE @Bob1 INT;

SET @Bob1 = dbo.OptionalParameterTest(100, DEFAULT);

SELECT @Bob1;
-- Returns: 102

반면에 EXECUTE함수 인 경우 저장 프로 시저에서와 같이 기본값을 가진 매개 변수를 실제로 선택적으로 처리 할 수 ​​있습니다. 매개 변수 이름을 지정하지 않고 첫 번째 n 매개 변수를 전달할 수 있습니다 .

DECLARE @Bob2 INT;

EXEC @Bob2 = dbo.OptionalParameterTest 50;

SELECT @Bob2;
-- Returns: 52

저장 프로 시저와 마찬가지로 매개 변수 이름을 다시 지정하여 첫 번째 매개 변수를 건너 뛸 수도 있습니다.

DECLARE @Bob3 INT;

EXEC @Bob3 = dbo.OptionalParameterTest @Param2 = 50;

SELECT @Bob3;
-- Returns: 51

최신 정보

왜 EXEC저장 프로 시저와 같이 구문 을 사용하여 스칼라 UDF를 호출 할 수 있습니까? 경우에 따라 쿼리에 추가하고 반환 된 행 집합을 조작 할 수 있기 때문에 UDF로 사용하기에 적합한 UDF가있을 수 있습니다. 반면에 코드가 저장 프로 시저에있는 경우에는 일련의 행을 반복합니다. 그러나 다른 UDF 내에서 단일 값으로 해당 함수를 호출하려는 경우가 있습니다. 단일 값에 대한 UDF 호출은 다음 중 하나로 수행 할 수 있습니다.

SELECT dbo.UDF('some value');

이 경우 결과 집합에서 반환 값을 얻습니다 (결과 집합이 작동하지 않음). 또는 다음과 같이 수행 할 수 있습니다.

DECLARE @Dummy INT;

SET @Dummy = dbo.UDF('some value');

이 경우 @Dummy변수 를 선언해야 합니다.

그러나 EXEC구문을 사용하면 이러한 성가심을 모두 피할 수 있습니다.

EXEC dbo.UDF 'some value';

또한 스칼라 UDF는 실행 계획을 캐시합니다. 이는 UDF에 실행 계획이있는 쿼리가있는 경우 매개 변수 스니핑 문제가 발생할 수 있음을 의미합니다. EXEC구문 을 사용할 수있는 시나리오의 경우 WITH RECOMPILE옵션을 사용하여 해당 실행에 대한 계획 컴파일 된 값을 무시할 수도 있습니다. . 예를 들면 다음과 같습니다.

설정:

GO
CREATE FUNCTION dbo.TestUDF (@Something INT)
RETURNS INT
AS 
BEGIN
   DECLARE @Ret INT;
   SELECT @Ret = COUNT(*)
   FROM   sys.indexes si
   WHERE  si.[index_id] = @Something;

   RETURN @Ret;
END;
GO

테스트:

DECLARE @Val INT;

SET @Val = dbo.TestUDF(1);
SELECT @Val;

EXEC @Val = dbo.TestUDF 0 -- uses compiled value of (1)
SELECT @Val;

EXEC @Val = dbo.TestUDF 0 WITH RECOMPILE; -- uses compiled value of (0)
SELECT @Val;

EXEC @Val = dbo.TestUDF 3 -- uses compiled value of (1)
SELECT @Val;

사용 권한의 차이는 저장 프로 시저와 마찬가지로 EXEC를 사용하여 스칼라 값 사용자 정의 함수를 실제로 호출 할 수 있기 때문이라고 생각합니다. 그러나 실제로는 테이블 소스로 선택할 수 없습니다. 예를 들면 다음과 같습니다.

DECLARE @date datetime
EXEC @date = dbo.first_day_of_month '8/14/2015'
SELECT @date

이 경우 dbo.first_day_of_month는 사용자 정의 함수입니다. 왜 그런 식으로 함수를 호출 해야할지 모르겠지만 일관성을 유지하기 위해 SELECT 대신 EXECUTE 권한이 필요하다고 추측합니다. 요즘은 아마도 호환 수하물로만 들고있을 것입니다.