[sql] SQL WHERE 절이 단락 되었습니까?

Program / 글쓴이

SQL WHERE 절의 부울 표현식 이 단락 평가
 됩니까?

예를 들면 다음과 같습니다.

SELECT *
FROM Table t
WHERE @key IS NULL OR (@key IS NOT NULL AND @key = t.Key)

@key IS NULL 이 true로 평가 되면 @key IS NOT NULL AND @key = t. 키가 평가됩니까?

아니라면 왜 안됩니까?

그렇다면, 보장됩니까? ANSI SQL의 일부입니까, 아니면 데이터베이스 특정입니까?

데이터베이스에 특정한 경우 SqlServer? 신탁? MySQL?

답변

ANSI SQL Draft 2003 5WD-01- 프레임 워크 -2003-09.pdf

6.3.3.3 규칙 평가 순서

[…]

우선 순위가 형식이나 괄호로 결정되지 않은 경우, 효과적인 표현 평가는 일반적으로 왼쪽에서 오른쪽으로 수행됩니다. 그러나
표현식이 실제로 왼쪽에서 오른쪽으로 평가되는지 여부, 특히 피연산자 또는 연산자가 조건을 발생시킬 수 있거나 표현식의 모든 부분을 완전히 평가하지 않고 표현식의 결과를 결정할 수있는 경우 구현에 따라 다릅니다 .

답변

위의 단락은 실제로 사용할 수 없습니다.

필요한 경우 Case 문을 제안합니다.

Where Case when Expr1 then Expr2 else Expr3 end = desiredResult

Expr1항상 평가하지만 중 하나입니다 Expr2및 Expr3행마다 평가됩니다.

답변

나는 이것이 세 가지 이유로 단락되지 않은 것처럼 작성하는 경우 중 하나라고 생각합니다.

  1. MSSQL의 경우 명확한 위치에서 BOL을 살펴 보아도 해결되지 않으므로 정식으로 모호합니다.

  2. 적어도 내 코드가 작동한다는 것을 알고 있기 때문입니다. 그리고 더 중요한 것은, 나를 따르는 사람들도 마찬가지입니다. 그래서 나는 같은 질문을 반복해서 반복하도록 걱정하지 않습니다.

  3. 여러 DBMS 제품에 대해 자주 글을 쓰며 쉽게 해결할 수 있다면 차이점을 기억하고 싶지 않습니다.

답변

SQL Server (2005)의 단락이 보장되는 것은 아닙니다. SQL Server는 효과적인 실행 계획을 세우기 위해 많은 것들 (인덱스, 통계, 테이블 크기, 리소스 등)을 고려한 최적화 알고리즘을 통해 쿼리를 실행합니다. 이 평가 후에는 단락 논리가 보장된다고 확신 할 수 없습니다.

나는 얼마 전에 같은 질문을 겪었고 나의 연구는 실제로 결정적인 대답을주지 못했다. 작은 쿼리를 작성하면 작동한다는 증거를 얻을 수 있지만 데이터베이스의로드가 증가함에 따라 테이블이 커지고 데이터베이스에서 상황이 최적화되고 변경된다는 결론을 얻을 수 있습니다. 보류. 나는주의를 기울일 수 없었고 단락을 보장하기 위해 WHERE 절에서 CASE를 사용했습니다.

답변

데이터베이스 작동 방식을 명심해야합니다. 매개 변수화 된 쿼리가 주어지면 db는 매개 변수 값없이 해당 쿼리를 기반으로 실행 계획을 작성합니다. 이 쿼리는 실제 제공된 값에 관계없이 쿼리가 실행될 때마다 사용됩니다. 쿼리가 특정 값으로 단락되는지 여부는 실행 계획에 중요하지 않습니다.

답변

나는 일반적으로 이것을 선택적 매개 변수에 사용합니다. 단락과 동일합니까?

SELECT  [blah]
FROM    Emp
WHERE  ((@EmpID = -1) OR (@EmpID = EmpID))

이것은 나에게 -1을 전달하거나 옵션의 속성 검사를 설명 할 수있는 옵션을 제공합니다. 때로는 여러 테이블 또는 바람직하게는 뷰를 조인하는 것이 포함됩니다.

DB 엔진에 제공하는 추가 작업을 완전히 확신하지 못하는 매우 편리합니다.

답변

SQL Server의 경우 버전에 따라 다르다고 생각하지만 SQL Server 2000에 대한 나의 경험은 @key가 null 인 경우에도 여전히 @key = t를 평가한다는 것입니다. 즉, WHERE 절을 평가할 때 효율적인 단락을 수행하지 않습니다.

사용자가 다양한 기준을 입력하거나 입력 할 수없는 유연한 쿼리를 수행하는 방법으로 예제와 같은 구조를 추천하는 사람들을 보았습니다. 내 관찰은 @key가 null 일 때 Key가 쿼리 계획에 여전히 관여하고 Key가 색인화되면 색인을 효율적으로 사용하지 않는다는 것입니다.

다양한 기준을 가진 이런 종류의 유연한 쿼리는 동적으로 생성 된 SQL이 실제로 가장 좋은 방법 일 수 있습니다. @key가 null이면 쿼리에 전혀 포함시키지 않습니다.