SQL ANSI-92 표준이 ANSI-89보다 더 잘 채택되지 않는 이유는 무엇입니까?

내가 일한 모든 회사에서 사람들이 여전히 ANSI-89 표준으로 SQL 쿼리를 작성하고 있음을 발견했습니다.

select a.id, b.id, b.address_1
from person a, address b
where a.id = b.id

ANSI-92 표준 대신 :

select a.id, b.id, b.address_1
from person a
inner join address b
on a.id = b.id

이와 같은 매우 간단한 쿼리의 경우 가독성에 큰 차이가 없지만 큰 쿼리의 경우 테이블을 나열하여 조인 기준을 그룹화하면 조인에서 문제가 발생할 수있는 위치를 훨씬 쉽게 확인할 수 있습니다. WHERE 절에 모든 필터링을 유지하겠습니다. Oracle의 (+) 구문보다 외부 조인이 훨씬 직관적이라고 생각합니다.

내가 ANSI-92를 사람들에게 전파하려고 할 때, ANSI-89보다 ANSI-92를 사용하면 구체적인 성능상의 이점이 있습니까? 제가 직접 시도해 보 겠지만 여기에있는 Oracle 설정으로는 EXPLAIN PLAN을 사용할 수 없습니다. 사람들이 코드를 최적화하는 것을 원하지 않을까요?

Peter Gulutzan과 Trudy Pelzer의 "SQL 성능 튜닝"에 따르면 테스트 한 6 개 또는 8 개의 RDBMS 브랜드 중 SQL-89와 SQL-92 스타일 조인의 최적화 또는 성능에는 차이가 없었습니다. 대부분의 RDBMS 엔진은 쿼리를 최적화하거나 실행하기 전에 구문을 내부 표현으로 변환하므로 사람이 읽을 수있는 구문은 차이가 없다고 가정 할 수 있습니다.

또한 SQL-92 구문을 전파하려고합니다. 승인 된 지 16 년이 지난 지금은 사람들이 사용하기 시작할 때입니다! 이제 모든 브랜드의 SQL 데이터베이스가이를 지원하므로 비표준 (+)Oracle 구문 또는 *=Microsoft / Sybase 구문 을 계속 사용할 이유가 없습니다 .

SQL-89 습관의 개발자 커뮤니티를 깨는 것이 왜 그렇게 어려운지에 관해서는 책, 잡지 기사의 고대 예를 사용하여 복사 및 붙여 넣기로 코딩하는 프로그래머로 구성된 대규모 "피라미드 기반"이 있다고 가정 할 수 있습니다. 또는 다른 코드 기반으로,이 사람들은 추상적으로 새로운 구문을 배우지 않습니다. 어떤 사람들은 패턴 매칭을하고 어떤 사람들은 암 기적으로 배웁니다.

하지만 점차적으로 SQL-92 구문을 사용하는 사람들이 예전보다 더 자주 보입니다. 저는 1994 년부터 온라인으로 SQL 질문에 답해 왔습니다.

ANSI092 표준에는 꽤 흉악한 구문이 포함되어 있습니다. Natural Join 은 하나이고 USING 절은 다른 것입니다. IMHO, 테이블에 열을 추가해도 코드가 깨져서는 안되지만 NATURAL JOIN은 가장 심각한 방식으로 중단됩니다. 중단하는 "가장 좋은"방법은 컴파일 오류입니다. 예를 들어 당신이 * 곳을 선택하면, 열의 추가 할 수컴파일에 실패했습니다. 실패하는 다음으로 가장 좋은 방법은 런타임 오류입니다. 사용자가 볼 수 있기 때문에 더 나쁘지만 여전히 무언가를 깨뜨렸다는 멋진 경고를 제공합니다. ANSI92를 사용하고 NATURAL 조인을 사용하여 쿼리를 작성하면 컴파일 타임에 중단되지 않고 런타임에 중단되지 않고 쿼리가 갑자기 잘못된 결과를 생성하기 시작합니다. 이러한 유형의 버그는 교활합니다. 보고서가 잘못되고 잠재적으로 재무 공개가 잘못되었습니다.

NATURAL 조인에 익숙하지 않은 사용자를 위해. 두 테이블에있는 모든 열 이름에서 두 테이블을 조인합니다. 4 열 키가 있고 입력하는 데 지쳤을 때 정말 멋집니다. 문제는 Table1에 DESCRIPTION이라는 기존 열이 있고 Table2에 새 열을 추가 할 때 발생합니다. 이름은 모르겠습니다. mmm, DESCRIPTION과 같은 무해한 것입니다. 이제 VARCHAR2에서 두 테이블을 조인합니다. (1000) 필드는 자유 형식입니다.

USING 절은 위에서 설명한 문제 외에도 전체 모호성을 유발할 수 있습니다. 다른 SO 게시물 에서 누군가이 ANSI-92 SQL을 보여주고 그것을 읽는 데 도움을 요청했습니다.

SELECT c.* 
FROM companies AS c 
JOIN users AS u USING(companyid) 
JOIN jobs AS j USING(userid) 
JOIN useraccounts AS us USING(userid) 
WHERE j.jobid = 123

이것은 완전히 모호합니다. 회사와 사용자 테이블 모두에 UserID 열을 넣었는데 불만이 없습니다. 회사의 UserID 열이 해당 행을 마지막으로 수정 한 사람의 ID이면 어떻게됩니까?

나는 진지합니다. 누구든지 그러한 모호성이 필요한 이유를 설명 할 수 있습니까? 왜 표준에 바로 내장되어 있습니까?

코딩을 통해 거기에 복사 / 붙여 넣기하는 개발자 기반이 많다는 것이 Bill이 맞다고 생각합니다. 사실, 저는 ANSI-92에 관해서는 제가 그런 사람이라는 것을 인정할 수 있습니다. 내가 본 모든 예는 괄호 안에 중첩되는 여러 조인을 보여줍니다. 정직함은 SQL에서 테이블을 선택하기 어렵게 만듭니다. 그러나 SQL92 evangilist는 실제로 조인 순서를 강제 할 것이라고 설명했습니다. JESUS ​​... 내가 본 모든 Copy Paster는 이제 실제로 조인 순서를 강제하고 있습니다. 작업 시간의 95 %는 최적화 프로그램, 특히 copy / paster 에게 더 잘 남았습니다 .

토 말락이 말했을 때 바로 잡았습니다.

사람들은 새로운 구문으로 전환하지 않습니다.

그것은 나에게 무언가를 주어야하고 나는 상승세를 보지 못한다. 그리고 만약 긍정적 인면이 있다면, 부정적인 것은 무시하기에는 너무 큰 앨버트로스입니다.

몇 가지 이유가 떠 오릅니다.

• 사람들은 습관으로 그것을한다
• 사람들은 게으르고 타이핑이 적기 때문에 "이전 스타일"조인을 선호합니다.
• 초보자는 종종 SQL-92 조인 구문으로 머리를 감싸는 데 문제가 있습니다.
• 사람들은 새로운 구문으로 전환하지 않습니다.
• 사람들은 새로운 구문이 갖는 이점을 알지 못합니다. 주로 외부 조인을 수행 하기 전에 테이블을 필터링 할 수 있으며 WHERE 절만 있으면 테이블을 필터링 할 수 있습니다 .

필자는 모든 조인을 SQL-92 구문으로 수행하고 가능한 한 코드를 변환합니다. 더 깨끗하고 읽기 쉽고 강력한 방법입니다. 그러나 쿼리 결과를 변경하지 않고 더 많은 타이핑 작업으로 인해 상처를 입었다 고 생각할 때 누군가가 새로운 스타일을 사용하도록 설득하기는 어렵습니다.

위의 NATURAL JOIN 및 USING 게시물에 대한 응답입니다.

왜 이것을 사용할 필요가 있다고 생각합니까? ANSI-89에서는 사용할 수 없었고 바로 가기로 만 볼 수있는 ANSI-92 용으로 추가되었습니다.

나는 결코 조인을 기회에 남기지 않고 항상 테이블 / 별칭 및 ID를 지정합니다.

나에게 유일한 방법은 ANSI-92입니다. 더 장황하고 구문은 ANSI-89 추종자들이 좋아하지 않지만 JOINS와 FILTERING을 깔끔하게 분리합니다.

먼저 SQL Server에서 외부 조인 구문 (* =)이 항상 올바른 결과를 제공하지 않는다고 말하겠습니다. 외부 결합이 아닌 교차 결합으로 해석하는 경우가 있습니다. 따라서 사용을 중단해야 할 좋은 이유가 있습니다. 그리고이 외부 조인 구문은 더 이상 사용되지 않는 기능이며 SQL Server 2008 이후 SQL Server의 다음 버전에 포함되지 않을 것입니다. 내부 조인은 여전히 ​​수행 할 수 있지만 도대체 왜 누구를 원할까요? 불분명하고 유지하기가 훨씬 더 어렵습니다. 조인의 일부가 무엇이고 실제로 where 절이 무엇인지 쉽게 알 수 없습니다.

이전 구문을 사용하지 말아야한다고 생각하는 한 가지 이유는 조인과 조인이하는 일과하지 않는 일을 이해하는 것이 SQL 코드를 작성하는 모든 사람에게 중요한 단계이기 때문입니다. 조인을 완전히 이해하지 않고 SQL 코드를 작성해서는 안됩니다. 그것들을 잘 이해한다면 아마도 ANSI-92 구문이 더 명확하고 유지하기 쉽다는 결론에 도달 할 것입니다. 이전 구문보다 ANSI-92 구문을 사용하지 않는 SQL 전문가를 만나 본 적이 없습니다.

이전 코드를 사용하는 내가 만났거나 만난 대부분의 사람들은 조인을 진정으로 이해하지 못하여 데이터베이스를 쿼리 할 때 문제가 발생합니다. 이것은 내 개인적인 경험이므로 항상 사실이라고 말하는 것은 아닙니다. 하지만 데이터 전문가로서 저는 몇 년 동안이 쓰레기를 너무 많이 고쳐서 믿지 못했습니다.

저는 학교에서 ANSI-89를 배웠고 몇 년 동안 업계에서 일했습니다. 그런 다음 8 년 동안 멋진 DBMS 세계를 떠났습니다. 그러나 나는 돌아 왔고이 새로운 ANSI 92 재료를 가르치고있었습니다. Join On 구문을 배웠고 이제 실제로 SQL을 가르치고 새로운 JOIN ON 구문을 권장합니다.

그러나 내가 본 단점은 상호 관련된 하위 쿼리가 ANSI 92 조인에 비추어 볼 때 의미가없는 것 같습니다. 조인 정보가 WHERE에 포함되고 상관 된 하위 쿼리가 WHERE에 "조인"되었을 때 모든 것이 정확하고 일관된 것처럼 보였습니다. ANSI 92 테이블 조인 기준이 WHERE에없고 하위 쿼리 "조인"이 있으면 구문이 일치하지 않는 것 같습니다. 반면에 이러한 불일치를 "수정"하려고하면 상황이 더욱 악화 될 것입니다.

확실히 답은 모르겠네요 .. 이것은 종교적인 전쟁입니다. (Mac-Pc 나 다른 것보다 덜한 정도입니다)

꽤 최근까지도 오라클 (그리고 다른 벤더들도)은 ANSI-92 표준 (오라클 v9 또는 그 정도에 있다고 생각합니다)을 채택하지 않았기 때문에 DBA / Db 개발자는 여전히 이러한 버전을 사용하고 있거나 (또는 ​​이러한 버전을 사용하는 서버간에 코드를 이식 할 수 있기를 원했기 때문에 이전 표준을 고수해야했습니다.

새로운 조인 구문이 훨씬 더 읽기 쉽고 이전 구문이 여러 가지 잘 문서화 된 시나리오에서 잘못된 (잘못된) 결과를 생성하기 때문에 정말 부끄러운 일입니다.

• 특히, 조인의 "외부"쪽에있는 테이블의 비조 인 관련 열에 조건부 필터링 조건자가있는 경우 외부 조인입니다.

관성과 실용성.

ANSI-92 SQL은 터치 타이핑과 같습니다. 이론적으로는 언젠가 모든 것이 더 나아질 수 있지만 이제는 네 손가락으로 키를 보면서 훨씬 빠르게 입력 할 수 있습니다. 나는 앞으로 나아 가기 위해 뒤로 갈 필요가있을 것이고, 보상이있을 것이라는 보장도 없다.

SQL 작성은 내 직업의 약 10 %입니다. ANSI-89 SQL로 해결할 수없는 문제를 해결하기 위해 ANSI-92 SQL이 필요하면이를 사용하겠습니다. (사실 Access에서 사용합니다.) 항상 사용하면 기존 문제를 훨씬 빨리 해결하는 데 도움이된다면 시간을 들여 동화 할 것입니다. 그러나 구문에 대해 생각하지 않고도 ANSI-89 SQL을 만들 수 있습니다. 문제를 해결하기 위해 보수를받습니다. SQL 구문에 대해 생각하는 것은 시간과 고용주의 돈을 낭비하는 것입니다.

언젠가, 어린 Grasshopper 여러분, 여러분은 SQL3 (또는 무엇이든)을 사용해야한다고 징징 거리는 젊은이들로부터 ANSI-92 SQL 구문 사용을 방어 할 것입니다. 그리고 당신은 이해할 것입니다. :-)

SQL 92 조인 구문을 지원하지 않는 SQL Server 6.5 용으로 원래 작성된 쿼리가 있습니다.

select foo.baz
from foo
  left outer join bar
  on foo.a = bar.a

대신 다음과 같이 작성되었습니다.

select foo.baz
from foo, bar
where foo.a *= bar.a

쿼리는 한동안 주위에 있었고 관련 데이터가 누적되어 쿼리가 너무 느리게 실행되었지만 완료하는 데 90 초가 걸렸습니다. 이 문제가 발생했을 때 SQL Server 7로 업그레이드했습니다.

인덱스 및 기타 부활절 달걀을 살펴본 후 조인 구문을 SQL 92와 호환되도록 변경했습니다. 쿼리 시간이 3 초로 줄었습니다.

전환해야 할 좋은 이유가 있습니다.

여기 에서 다시 게시되었습니다 .

두 구문을 모두 이해하는 데 충분한 SQL을 알고있는 일반 개발자의 관점에서 대답 할 수 있지만 필요할 때마다 정확한 구문 검색을 검색합니다 ... :-P (하루 종일 SQL을 수행하지 않습니다. , 수시로 일부 문제를 수정합니다.)

사실, 첫 번째 형식이 더 직관적이어서 두 테이블 사이에 명백한 계층 구조가 없다는 것을 알았습니다. 아마도 오래된 책으로 SQL을 배웠고 첫 번째 형식을 보여 주면 도움이되지 않을 것입니다 ... ;-)
그리고 Google 의 SQL 선택 검색에서 찾은 첫 번째 참조 (대부분 프랑스어 답변을 반환합니다 ... ) 먼저 이전 형식을 표시합니다 (그런 다음 두 번째 형식을 설명).

"왜"라는 질문에 대한 힌트를 드리기 만하면 ... ^ _ ^ 주제에 대한 좋은 현대 책 (DB 불가지론 자)을 읽어야합니다. 누군가 제안이 있다면 ...

저는 모든 학교에 대해 말할 수는 없지만 우리가 코스의 SQL 모듈을 할 때 대학에서 ANSI-92를 가르치지 않았고 ANSI-89를 가르쳤습니다. 예전 VAX 시스템 에서요! 쿼리 디자이너를 사용하여 몇 가지 쿼리를 작성한 다음 SQL 코드를 파고 들기 전까지는 ANSI-92에 노출되지 않았습니다. 조인을 완료하는 방법이나 구문의 의미에 대해 전혀 몰랐 음을 깨닫고 더 깊이 파고 들기 시작했습니다.

사용 가능한 문서가 많은 경우에 정확히 직관적이지 않고 사람들이 자신이 알고있는 것을 고수하는 경향이 있고 대부분의 경우 작업을 완료하기 위해 필요한 것 이상으로 배우려고 노력하지 않는다는 점을 감안할 때 채택이 왜 그렇게 오래 걸리는지 쉽게 알 수 있습니다.

물론, 땜질하고 이해하는 것을 좋아하는 기술 전도자들이 있으며, "새로운"원칙을 채택하고 나머지를 변환하려고하는 유형 인 경향이 있습니다.

이상하게도 많은 프로그래머가 학교를 졸업하고 진학을 그만두는 것 같습니다. 이것이 그들이 배운 것이기 때문에 이것이 행해지는 방법이라고 생각합니다. 학교가 기본을 가르치고 나머지를 스스로 배울 수있는 충분한 이해를 제공하기위한 목적 일 뿐이며 실제로 알아야 할 내용의 표면을 간신히 긁 었다는 사실을 깨달은 것은 눈을 깜빡이는 것을 풀 때까지입니다. 이제 그 길을 계속하는 것이 당신의 일입니다.

물론 그것은 내 경험을 바탕으로 한 내 의견입니다.

1) OUTER JOIN을 작성하는 표준 방법, * = 또는 (+) =

2) 내추럴 조인

3) 데이터베이스 엔진에 따라 ANSI-92 추세가 더 최적화됩니다.

4) 수동 최적화 :

다음 구문 (ANSI-89)이 있다고 가정 해 보겠습니다.

(1)select * from TABLE_OFFICES to,BIG_TABLE_USERS btu
where to.iduser=tbu.iduser and to.idoffice=1

다음과 같이 작성할 수 있습니다.

(2)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser
where to.idoffice=1

또한 :

(3)select * from TABLE_OFFICES to
inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser and to.idoffice=1

그들 모두 (1), (2), (3)은 동일한 결과를 반환하지만 다르게 최적화되어 있으며 데이터베이스 엔진에 따라 다르지만 대부분은 다음을 수행합니다.

• (1) 데이터베이스 엔진이 최적화를 결정합니다.
• (2) 두 테이블을 결합한 다음 사무실별로 필터를 수행합니다.
• (3) idoffice를 사용하여 BIG_TABLE_USERS를 필터링 한 다음 두 테이블을 조인합니다.

5) 긴 쿼리는 덜 지저분합니다.

사람들이 노인과 젊은 프로그래머, 연수생 및 신입생과의 실제 경험에서 ANSI-89를 사용하는 이유 :

• 책이 아닌 기존 코드에서 SQL을 배우고 코드에서 ANSI-89를 배웁니다.
• ANSI-89는 타이핑이 적기 때문에
• 그들은 그것에 대해 생각하지 않고 하나 또는 다른 스타일을 사용하며 둘 중 어느 것이 새롭고 오래된 것으로 간주되는지조차 알지 못하며 신경 쓰지 않습니다.
• 코드가 코드를 유지하는 다음 프로그래머에게도 전달된다는 생각은 존재하지 않습니다. 그들은 컴퓨터와 이야기하고 컴퓨터는 신경 쓰지 않는다고 생각합니다.
• "깨끗한 코딩"의 기술은 알려지지 않았습니다.
• 특히 프로그래밍 언어와 SQL에 대한 지식이 너무 부족하여 다른 곳에서 찾은 내용을 복사하여 붙여 넣습니다.
• 개인 취향

저는 개인적으로 ANSI-92를 선호하고 ANSI-89 구문에서 볼 수있는 모든 쿼리를 변경하는 것은 때때로 SQL 문을 더 잘 이해하기 위해서입니다. 하지만 내가 함께 일하는 대부분의 사람들은 많은 테이블에 대한 조인을 작성할만큼 숙련되지 않았다는 것을 깨달았습니다. 그들은 가능한 한 잘 코딩하고 SQL 문을 처음 접했을 때 기억 한 것을 사용합니다.

다음은 SQL-89와 SQL-92를 비교하고 다른 답변의 오해를 정리하는 몇 가지 요점입니다.

1. NATURAL JOINS끔찍한 생각입니다. 암시 적이며 테이블에 대한 메타 정보가 필요합니다. SQL-92에 대한 어떤 것도 사용이 필요하지 않으므로 단순히 무시하십시오 . 이 토론과 관련이 없습니다.
2. USING 두 가지 효과가 있습니다.
   1. 동등 조인의 결과 집합에 하나의 열만 생성합니다.
   2. 건전하고 건전한 관습을 시행합니다. SQL-89에서는 id두 테이블 모두에 열 을 작성하는 사람들이있었습니다 . 테이블을 조인하면 모호 해지고 명시적인 별칭이 필요합니다. 또한 id조인 의 s는 거의 확실히 다른 데이터를 가졌습니다. 사람과 회사를 결합하는 경우 이제 1 id을으로 person_id, 1 을 으로 별칭을 지정해야 id합니다 company_id. 그렇지 않으면 조인이 두 개의 모호한 열을 생성합니다. 테이블의 서로 게이트 키에 대해 전역 적으로 고유 한 식별자를 사용하는 것은 표준이 USING.
3. SQL-89 구문은 암시 적 CROSS JOIN. A CROSS JOIN는 집합을 줄이지 않고 암시 적으로 늘립니다. 일반적으로 원하는 것이 아닌 데카르트 조인을 생성하는와 FROM T1,T2동일 FROM T1 CROSS JOIN T2합니다. 먼 WHERE조건부로 제거되는 선택성을 줄이는 것은 디자인 중에 실수를 할 가능성이 더 높다는 것을 의미합니다.
4. SQL-89 ,및 SQL-92 명시 JOIN적은 우선 순위가 다릅니다. JOIN우선 순위가 더 높습니다. 설상가상으로 MySQL과 같은 일부 데이터베이스는 오랫동안이 문제가 발생했습니다. . 따라서 두 스타일을 혼합하는 것은 나쁜 생각이며 오늘날 훨씬 더 인기있는 스타일은 SQL-92 스타일입니다.

오라클은 ANSI-92를 전혀 구현하지 않습니다. 특히 Oracle Apps의 데이터 테이블에 열이 매우 잘 부여되어 있기 때문에 몇 가지 문제가 발생했습니다. 조인의 열 수가 약 1050 개 열을 초과하면 (앱에서 매우 쉽게 수행 할 수 있음) 논리적으로 의미가 전혀없는이 가짜 오류가 발생합니다.

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

이전 스타일의 조인 구문을 사용하도록 쿼리를 다시 작성하면 문제가 사라지고 이는 ANSI-92 조인의 구현에 대한 책임을 직시하는 것처럼 보입니다.

이 문제가 발생하기 전까지 저는 ASNI-92의 확고부동 한 프로모터였습니다. 구식 구문으로는 너무 쉽게 할 수있는 우발적 인 교차 조인 가능성을 줄이는 이점이 있기 때문입니다.

그러나 지금은 그것을 주장하기가 훨씬 더 어렵다는 것을 알게되었습니다. 그들은 오라클의 잘못된 구현을 지적하고 "감사합니다. 우리 방식대로 할 것입니다."라고 말합니다.

새로운 SQL 표준은 '호환성의 족쇄'라고 알려진 이전 표준의 모든 것을 상속합니다. 따라서 'old'/ 'comma-separated'/ 'unqualified'조인 스타일은 완벽하게 유효한 SQL-92 구문입니다.

이제 SQL-92 NATURAL JOIN가 필요한 유일한 조인 이라고 주장 합니다. 예를 들어, inner join중복 열을 생성하지 않기 때문에 더 우수하다고 주장합니다. 열 SELECT을 명확하게하기 위해 절에 더 이상 범위 변수가 없습니다 ! 그러나 모든 마음과 생각을 바꿀 수는 없으므로 개인적으로 레거시 조인 스타일이라고 생각하는 것을 계속 채택 할 코더와 함께 작업해야합니다 (범위 변수를 '별칭'이라고도합니다!). 이것은 팀워크의 특성이며 진공 상태에서 작동하지 않습니다.

SQL 언어에 대한 비판 중 하나는 의미 적으로 동등한 여러 구문 (일부는 관계형 대수를 사용하고 일부는 관계형 미적분을 사용)을 사용하여 동일한 결과를 얻을 수 있다는 것입니다. . 그래서 나는 '구식'조인에 대해 INNER. 내가 그것들을 다시 쓰는 데 시간을 할애할지 여부 NATURAL는 상황에 따라 다릅니다.