SQL : BETWEEN 대 <= 및> =

SQL : BETWEEN 대 <= 및> =

---

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(하루를 뺀 값). .

또한, 하한과 상한을 올바른 순서 (예 :)로 지정해야한다는 또 다른 문제점이 있습니다 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반 개방 간격으로 작동하지 않기 때문에 오류 일 가능성이 있으므로 항상 사용하는 날짜 / 시간 쿼리를 자세히 살펴 봅니다.

---

유일한 차이점은 각 쿼리에 대한 구문 적 설탕의 양이라고 생각합니다. BETWEEN은 두 번째 쿼리와 정확히 동일하게 말하는 매끄러운 방법입니다.

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

---

나는 당신이 범위에 대해 하나의 필드를 검사BETWEEN 하고 있다는 것을 독자에게 즉시 명확하게 하기 때문에 약간 선호 한다 . 테이블에 유사한 필드 이름이있는 경우 특히 그렇습니다.

예를 들어 테이블에 a transactiondate와 a 가 모두있는 transitiondate경우

transactiondate between ...

나는 테스트의 양쪽 끝이이 한 분야에 반대한다는 것을 즉시 알고 있습니다.

내가 읽으면

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

두 필드가 동일한 지 확인하려면 시간을 좀 더 들여야합니다.

Also, as a query gets edited over time, a sloppy programmer might separate the two fields. I've seen plenty of queries that say something like

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

If they try this with a BETWEEN, of course, it will be a syntax error and promptly fixed.

---

Logically there are no difference at all. Performance-wise there are -typically, on most DBMSes- no difference at all.

---

See this excellent blog post from Aaron Bertrand about why you should change your string format and how the boundary values are handled in date range queries.

---

Disclaimer: Everything below is only anecdotal and drawn directly from my personal experience. Anyone that feels up to conducting a more empirically rigorous analysis is welcome to carry it out and down vote if I'm. I am also aware that SQL is a declarative language and you're not supposed to have to consider HOW your code is processed when you write it, but, because I value my time, I do.

There are infinite logically equivalent statements, but I'll consider three(ish).

Case 1: Two Comparisons in a standard order (Evaluation order fixed)

A >= MinBound AND A <= MaxBound

Case 2: Syntactic sugar (Evaluation order is not chosen by author)

A BETWEEN MinBound AND MaxBound

Case 3: Two Comparisons in an educated order (Evaluation order chosen at write time)

A >= MinBound AND A <= MaxBound

Or

A <= MaxBound AND A >= MinBound

In my experience, Case 1 and Case 2 do not have any consistent or notable differences in performance as they are dataset ignorant.

However, Case 3 can greatly improve execution times. Specifically, if you're working with a large data set and happen to have some heuristic knowledge about whether A is more likely to be greater than the MaxBound or lesser than the MinBound you can improve execution times noticeably by using Case 3 and ordering the comparisons accordingly.

One use case I have is querying a large historical dataset with non-indexed dates for records within a specific interval. When writing the query, I will have a good idea of whether or not more data exists BEFORE the specified interval or AFTER the specified interval and can order my comparisons accordingly. I've had execution times cut by as much as half depending on the size of the dataset, the complexity of the query, and the amount of records filtered by the first comparison.

참고URL : https://stackoverflow.com/questions/1630239/sql-between-vs-and