문제

SQL Server 2000 및 2005의 경우:

  • 이 둘의 차이점은 무엇인가요? WHERE 조항?
  • 어떤 시나리오에서 어느 것을 사용해야 합니까?

쿼리 1:

SELECT EventId, EventName
FROM EventMaster
WHERE EventDate BETWEEN '10/15/2009' AND '10/18/2009'

쿼리 2:

SELECT EventId, EventName
FROM EventMaster
WHERE EventDate >='10/15/2009'
  AND EventDate <='10/18/2009'

(편집하다:두 번째 Eventdate가 원래 누락되었으므로 쿼리 구문이 잘못되었습니다.)

도움이 되었습니까?

해결책

그것들은 동일합니다 : BETWEEN 질문에서 더 긴 구문에 대한 속기입니다.

대체 더 긴 구문을 사용하십시오 BETWEEN 예를 들어 작동하지 않습니다

Select EventId,EventName from EventMaster
where EventDate >= '10/15/2009' and EventDate < '10/18/2009'

(메모 < 보다는 <= 두 번째 조건에서.)

다른 팁

그들은 동일합니다.

조심해야 할 한 가지는 DateTime에 대해 이것을 사용하는 경우 종료일의 일치가 오늘의 시작이라는 것입니다.

<= 20/10/2009

다음과 같지 않습니다.

<= 20/10/2009 23:59:59

(그것 ~일 것이다 일치합니다 <= 20/10/2009 00:00:00.000)

하지만 BETWEEN 읽고 유지하기가 쉽습니다. 폐쇄 간격이기 때문에 사용 권장은 거의 권장하지 않으며 앞에서 언급했듯이 시간 구성 요소가 없어도 날짜에 문제가 될 수 있습니다.

예를 들어 월별 데이터를 처리 할 때는 종종 날짜를 비교하는 것이 일반적입니다. BETWEEN first AND last, 그러나 실제로 이것은 일반적으로 글을 쓰는 것이 더 쉽습니다. dt >= first AND dt < next-first (시간 부품 문제를 해결하는 것) - 결정 이후 last 일반적으로 결정보다 한 걸음 더 길다 next-first (하루를 빼서).

또한 또 다른 Gotcha는 하위 및 상한이 올바른 순서 (즉 BETWEEN low AND high).

일반적으로 차이가 없습니다 BETWEEN 키워드는 모든 RDBMS 플랫폼에서 지원되지 않지만 두 쿼리는 동일해야합니다.

그것들은 동일하기 때문에 속도 나 다른 측면에서는 차이가 없습니다. 더 자연스럽게 보이는 것을 사용하십시오.

@marc_s, @Cloud 등이 언급했듯이. 그들은 기본적으로 폐쇄 범위에 대해 동일합니다.

그러나 모든 분수 시간 값은 폐쇄 범위 (더 큰 또는 평등 및 덜 동등합니다) 하프 오픈 범위와 달리 (더 크고 평등 및 적은 것보다) 최종 가치 ~ 후에 마지막으로 가능한 순간.

따라서 쿼리를 다음과 같이 다시 작성해야합니다.

SELECT EventId, EventName
  FROM EventMaster
 WHERE (EventDate >= '2009-10-15' AND
        EventDate <  '2009-10-19')    /* <<<== 19th, not 18th */

부터 BETWEEN 하프 오픈 간격으로 작동하지 않습니다. 오류가 발생하기 때문에 항상 사용하는 날짜/시간 쿼리를 열심히 살펴 봅니다.

유일한 차이점은 각 쿼리의 구문 설탕의 양입니다. 그 사이는 두 번째 쿼리와 정확히 동일하게 말하는 매끄러운 방법입니다.

내가 알지 못하는 RDBMS 특정 차이가있을 수 있지만 실제로 그렇게 생각하지 않습니다.

나는 약간의 선호도가 있다 BETWEEN 독자에게 즉시 명확하게 알려주기 때문입니다. 범위에 대해 하나의 필드를 확인하고 있습니다..테이블에 유사한 필드 이름이 있는 경우 특히 그렇습니다.

예를 들어, 우리 테이블에 transactiondate 그리고 transitiondate, 내가 읽으면

transactiondate between ...

나는 테스트의 양쪽 끝이 이 하나의 필드에 반대한다는 것을 즉시 압니다.

내가 읽으면

transactiondate>='2009-04-17' and transactiondate<='2009-04-22'

두 필드가 동일한지 확인하려면 잠시 시간을 더 투자해야 합니다.

또한 시간이 지남에 따라 쿼리가 편집되면 엉성한 프로그래머가 두 필드를 분리할 수도 있습니다.나는 다음과 같은 것을 말하는 많은 쿼리를 보았습니다.

where transactiondate>='2009-04-17'
  and salestype='A'
  and customernumber=customer.idnumber
  and transactiondate<='2009-04-22'

그들이 이것을 시도한다면 BETWEEN, 물론 구문 오류이므로 즉시 수정됩니다.

논리적으로 전혀 차이가 없습니다. 성능 측면에서는 대부분의 DBMSES에 전혀 차이가 없습니다.

이것 좀 봐 훌륭한 블로그 게시물 ~에서 아론 버트 랜드 문자열 형식을 변경 해야하는 이유와 경계 값이 날짜 범위 쿼리에서 처리되는 방법에 대해.

면책 조항 : 아래의 모든 것은 일화 적이며 개인적인 경험에서 직접 그려집니다. 보다 경험적으로 엄격한 분석을 수행하는 느낌이 든 사람은 내가 그것을 수행하고 투표 할 수있는 환영을 환영합니다. 또한 SQL은 선언적 언어라는 것을 알고 있으며, 글을 쓸 때 코드가 처리되는 방식을 고려할 필요는 없지만 시간을 소중히 여기기 때문에 그렇게합니다.

무한한 논리적으로 동등한 진술이 있지만 3 개 (ISH)를 고려할 것입니다.

사례 1 : 표준 순서의 두 가지 비교 (평가 순서 고정)

a> = minbound 및 a <= maxbound

사례 2 : 구문 설탕 (평가 순서는 저자가 선택하지 않음)

Minbound와 MaxBound 사이

사례 3 : 교육 된 순서의 두 가지 비교 (쓰기 시간에 선택된 평가 순서)

a> = minbound 및 a> = maxbound

또는

a> = maxbound 및 a> = minbound

내 경험상, 사례 1과 사례 2는 데이터 세트 무지이므로 성능에 일관되거나 주목할만한 차이가 없습니다.

그러나 사례 3은 실행 시간을 크게 향상시킬 수 있습니다. 구체적으로, 대규모 데이터 세트로 작업하고 있고 ㅏ 보다 클 가능성이 높습니다 MAXBOUND 또는보다 작은 Minbound 사례 3을 사용하고 그에 따라 비교를 주문하여 실행 시간을 눈에 띄게 향상시킬 수 있습니다.

내가 가진 하나의 유스 케이스는 특정 간격 내에서 기록에 대한 비 인덱스 날짜로 대규모 과거 데이터 세트를 쿼리하는 것입니다. 쿼리를 작성할 때, 지정된 간격 전에 또는 지정된 간격 이후에 더 많은 데이터가 있는지 여부에 대해 잘 알고 있으며 그에 따라 비교를 주문할 수 있습니다. 데이터 세트의 크기, 쿼리의 복잡성 및 첫 번째 비교에 의해 필터링 된 레코드의 양에 따라 실행 시간을 절반 정도 줄였습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top