2017-03-16 2 views
0

FROM 선언문에서 연산자를 사용하는 목적은 무엇입니까? 인터넷에서 제공되는 대부분의 예제는 유사한 조건을 WHERE 문에 넣어 해결할 수 있습니다.비표준 결합을 사용하는 데 유효한 유즈 케이스는 무엇입니까? >,> =, <, <=, <>

예 :

SELECT T1.OrderNum, T1.SpecialOfferAppliedDate AS SOAD, T1.SpecialOfferID, T2.StartDate, T2.EndDate 
FROM OrderDetail AS T1 
    INNER JOIN SpecialOffer AS T2 
      ON T1.SpecialOfferID = T2.SpecialOfferID 
WHERE T1.SOAD < T2.EndDate 
    AND T1.SOAD >= T2.StartDate 

편집 : 가입하고 난 비 동등으로 가입해야합니다 경우 제공 할 수있는 쿼리 사람이 있습니까

SELECT T1.OrderNum, T1.SpecialOfferAppliedDate AS SOAD, T1.SpecialOfferID, T2.StartDate, T2.EndDate 
FROM OrderDetail AS T1 
    INNER JOIN SpecialOffer AS T2 
     ON T1.SpecialOfferID = T2.SpecialOfferID 
     AND T1.SOAD < T2.EndDate 
     AND T1.SOAD >= T2.StartDate 

예는 WHERE 문을 사용하여? 이 시점에서 그것은 관련이있는 것으로 보입니다 : 개인 테이블 또는 테이블의 성능 향상을 위해

+1

'left join '이라면 첫 번째 형식을 사용하는 것이 더 좋을 것이다. 'null' 값에 대한 회계)는'inner join'으로 바꿀 것입니다. – SqlZim

+1

질문의 제목이 실제 질문과 관련이없는 것처럼 보입니다 ... ...? – Brandon

+1

왜 '어디'가 '켜기'보다 더 유효합니까? – Caleth

답변

1

SQL 2005 이전 버전에서는 SQL Server가 유지 관리되는 방식에 따라 이전 버전보다 약간 빠르다고 주장 할 수있었습니다. 나는 스코어를 더 빨리 제한하고 가장 큰 테이블을 먼저 찾아서 더 많은 것을 얻으려는 논리적 인 의미로이 방법을 사용하는 데 익숙해졌습니다.

EG : A, B, C 세 개의 테이블이 있다고 가정 해보십시오. A와 B에는 Dt (날짜) 필드에 수백만 개의 행과 일부 인덱스가 있습니다. 그리고 다른 테이블에는 겨우 몇 만 줄이있었습니다. 나는 많은 시간이 이런 짓을 할 것이다 :

Select (columns) 
From a 
    inner join b on a.Id = b.FId 
     and a.Id >= (somedate) 
    inner join c on b.Id = c.FId 

그것을 일반적으로 나에게 가능한 한 빨리 엔진의 관점에서 범위를 제한하기 위해 더 의미가 만든 문장은 실제로 SQL 서버에서 먼저 '에서' 내가 읽고 읽은 것의 엔진. 그래서 저는 수백만에 수백만의 모든 잠재력을 말하는 일련의 작업을하고있었습니다. 그 다음에는 내부 조인이 항상 요구 사항을 반환해야만 범위를 더 확장하고 제한해야한다는 것을 알고 있다는 것을 알 수 있습니다. 'Where'절은 똑같은 일을하지만 'From'문 다음에 평가되므로 더 느릴 것이라고 결론 내릴 수 있습니다.

그러나 성능과 가독성의 개발자 서클에는 지속적인 논쟁이 있습니다.

Select (columns) 
From a 
    inner join b on a.Id = b.FId 
     and a.Id >= (somedate) 
     and a.ocol = (criteria) 
    left outer join c on b.Id = c.FId 
where c.ocol = (criteria) 

누군가가 나에게 말할 수 : 내가 좋아하는 뭔가를했다 그래서이 "이봐 당신이 아니라에서 0.00001 부스트의 성능을 받고 어떻게 바로 Where 절에 모든 퍼팅에 대해?" 때때로 성능과 가독성을 균형있게 조절하는 경우가 있습니다. 비록 내가 정당하게 말할 수 있겠지만 뭔가가 매우 뒤떨어져 있다면 어떤면에서는 더 좋을 수도 있습니다. 그러나 일반적으로 나는 그것을 2012 년이나 어쩌면 2008 R2 주위에서 읽었습니다. Microsoft는 엔진을 다시 작성하여 본질적으로 더 이상 실제로 시간을 절약하지 못하도록보다 효율적으로 컴파일했습니다. 당신은 당신이 원하는 경우 비록 직접 테스트 할 수 있습니다

실행이 SQL 관리 Studio에 :

SET 통계 TIME ON; 이 같은

그리고 당신은 볼 것들 : 메시지 탭에서

SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 2 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 2 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 8 ms. 

. 물론 뷰 패널에서 더 무거운 '클라이언트 통계'탭을 수행하고 더 자세한 내용을 볼 수도 있습니다. 많은 사람들이 범위를 더 빨리 제한하기 위해 엔진 실행을보다 효율적으로 사용하기 위해 사용하는 구문 론적 트릭 일뿐입니다. 그러나 재 작업으로 더 이상 효과를 내지 못할 수도 있습니다.나는 여전히 그것을 사용하지만 내 자신에 코딩하면 사물에 익숙해진다. :)

0

INNER JOIN은 사용해야하는 ANSI 구문입니다. 가능하다면 WHERE에 추가하는 것을 피하는 것이 가장 좋습니다.

또한 일반적으로 테이블이 많을 때 더 읽기 쉽다고 생각되며 필요가 발생할 때마다 쉽게 OUTER JOIN으로 바꿀 수 있습니다.

성능면에서 차이가 없습니다.

+0

두 쿼리 모두 '내부 조인'을 명시 적으로 사용합니다 –

+0

yeap 죄송합니다.이 질문에 대한 답변을 수정했습니다 ... – Lostblue

+0

내 이유 문장에 기준을 두지 않는 이유는 무엇입니까? 개인적인 취향/개인적인 가독성입니까? 나에 대한 기준은 항상 논리적으로 WHERE에 배치되어 왔으며 현재 WHERE 구문이 이해하기가 복잡 해지는 문제에 대해서는 본 적이 없다. –

1

모든 조인은 모든 작업을 수행하는 WHERE 문으로 다시 작성할 수 있습니다. 당신이 WHERE

를 사용할 때 LEFT | RIGHT | FULL JOIN가지 경우가 더 다루기 얼마나

SELECT table1.cols ..., table2.cols ... 
FROM table1 
JOIN table2 ON TRUE 
WHERE table1.id = table2.id 

UNION SELECT cols, null ... -- for LEFT or FULL JOIN 
FROM table1 WHERE id NOT IN (SELECT id FROM table2) 

UNION SELECT null ..., cols -- for RIGHT or FULL JOIN 
FROM table2 WHERE id NOT IN (SELECT id FROM table1) 

참고 개인적으로 많은 JOIN ... ON보다는 WHERE 절에 문제의 관계를 표현하는 것을 선호합니다. "이 주문에 적용되는 특별 제안"이라고 할 수있는 귀하의 예에서 "이 주문에 적용"은 신원과 시간 구성 요소를 모두 가지고 있습니다.

1

모든 것이 가독성과 명료성에 관한 것입니다.

두 테이블을 함께 결합하면 해당 조인의 논리를 한 곳에 보관하는 것이 좋습니다. 귀하의 예제에서 논리 일치 레코드는 외래 키 관계 (T1.SpecialOfferID = T2.SpecialOffID)와 구매 날짜 및 특별 행사 날짜 모두에 의존합니다. 날짜 논리는 조인에 필수적으로 나타납니다. 해당 날짜 범위 내에 맞는 일치 항목 만 검색하려고합니다.

"where"절에는 주문의 가치, 특별 행사의 창시자 등 무엇이든간에 합류 논리에 영향을 미치지 않는 다른 제한 사항이있을 수 있습니다.

일반적으로 어떤 절이 조인의 본질적인 부분이며 데이터 집합에 대한 세부 사항 인 해석 문제입니다. 실용적인면에서 두 가지 용도는 동일합니다.

"비 - 동일"부분은 - 나는 믿습니다 - 그것이 결합을 정의 할 수있는 방식으로 만 관련이 있습니다. 귀하의 예에서 "ID와 일치하는 레코드가 날짜 범위 내에 있어야합니다"라는 로직이 있습니다.

조인 문의 비교를 포함하는 사용 사례는 다음과 같습니다. 비즈니스 도메인에서는 전체 조인 조건이 충족 될 때만 이러한 레코드가 함께 속한다고 제안합니다.

where 절에 비교를 포함시키는 유스 케이스는 원하는 결과를 구체화하지만 비즈니스 도메인에 어떤 레코드가 "속해 있는지"정의하지 않습니다.

+0

그렇다면 두 가지 사용법이 동일하다는 것을 말하면서, 다른 것을 하나씩 사용하는 특별한 사용 사례가 없다는 말입니까? –

+1

답변을 업데이트했습니다. 보기의 실행 관점에서, 그들은 동일합니다 - 그것은 실제로 코딩 스타일의 것입니다 –

0

Offhand 나는 불평등을 수반하는 관계로 인해 자연스럽게 관련 될 두 테이블의 예를 생각할 수 없습니다. 내가 쓰는 쿼리를 사용하는 이점을 활용할 수있는 쿼리를 생각하는 것도 여전히 어렵지 않습니다. 나이별로 사람들의 순위를 정하고 싶다고 가정 해 봅시다. 단순함을 위해 관계를 가정하지 마십시오.

select p.name, count(*) as age_rank 
from people p inner join people p2 on p2.birth_date <= p.birth_date 
group by p.name 

분석 기능과 같은 고급 SQL 기능에는 자체 조인 기능이 더 이상 필요하지 않습니다.

로직 조건을 fromwhere 사이에서 움직이는 것에 초점을 맞춘 것 같습니다. 외부 조인을 사용하기 시작하면 쿼리가 더 이상 의미 상 동일하지 않으므로 더 이상 자유가 없습니다.

+0

이 문제는 생년월일로 사람들을 정렬하여 해결할 수 있습니다. 겉으로는 불필요한 자기 조인 대신에 FROM에 기준을 두는 것이 더 유익하고 필요한 유스 케이스를 찾으려고합니다. 당신의 질문은 제 방식대로하는 것보다 많은 이점이 있습니까? –

+0

물론 결과를 정렬하고 * 볼 수는 있지만 쿼리 자체에서 내부적으로 사용할 수있는 데이터는 제공하지 않습니다. 논점은 조인과 관련된 로직 만 조인 조건에 넣는 것입니다. 옵티마이 저는 일반적으로 필요에 따라 실행 계획 자체를 구성하는 데 좋습니다. 그러나 최적화가 내가 이점을 가질 것이라고 생각할 수있는 유일한 이유입니다. 위 외부 조인에 대한 내 노트를 참조하십시오. – shawnt00

관련 문제