기본 키 / 외부 키 일치가 조인에 사용되지 않는 이유는 무엇입니까?

많은 DBMS (예 : mysql, postgres, mssql)가 fk 및 pk 조합을 사용하여 데이터 변경 사항을 제한하는 경우를 제외하고는 기본적으로 조인 할 열을 자동으로 선택하는 데 거의 사용되지 않습니다 (이름과의 자연 조인처럼). 왜 그런 겁니까? pk / fk를 사용하여 두 테이블 사이의 관계를 이미 정의한 경우 데이터베이스에서 해당 테이블을 조인하면 pk / fk 열에서 조인하려는 이유를 알 수없는 이유는 무엇입니까?

편집 : 이것을 명확히하기 위해 :

table1과 table2가 있다고 가정하십시오. table1 하나는 열 a에 외래 키를 가지고 있으며, 이것은 테이블 2의 기본 키인 b 열을 참조합니다. 이제이 테이블을 조인하면 다음과 같이해야합니다.

SELECT * FROM table1
JOIN table2 ON table1.a = table2.b

그러나 table1.a가 table2.b를 참조하는 키를 이미 정의 했으므로 DBMS 시스템이 table1.a 및 table2.b를 조인 열로 자동 사용하게하는 것은 어렵지 않아야합니다. 하나만 사용하면됩니다 :

SELECT * FROM table1
AUTO JOIN table2

그러나 많은 DBMS는 이와 같은 것을 구현하지 않는 것 같습니다.

많은 경우 두 테이블을 결합하는 방법은 여러 가지가 있습니다. 많은 예는 다른 답변을 참조하십시오. 물론, 그러한 경우에는 '자동 조인'을 사용하는 것이 오류라고 말할 수 있습니다. 그런 다음 사용할 수있는 간단한 사례 만 남게됩니다.

그러나 심각한 단점이 있습니다! 오늘 올바른 쿼리는 동일한 테이블에 두 번째 FK를 추가하는 것만으로 내일 오류가 될 수 있습니다!

다시 말하겠습니다. 열을 추가하면 해당 열을 사용하지 않는 쿼리가 '올바른'에서 '오류'로 바뀔 수 있습니다!

제정신 스타일 가이드가이 기능을 사용하는 것을 금지하는 것은 유지 관리의 악몽입니다. select *같은 이유로 대부분 금지 하고 있습니다!

성능이 향상되면이 모든 것이 허용됩니다. 그러나 그렇지 않습니다.

요약하면 이 기능은 제한된 간단한 경우에만 사용할 수 있으며 성능을 향상시키지 않으며 대부분의 스타일 가이드는 어쨌든 사용을 금지합니다.

따라서 대부분의 데이터베이스 공급 업체가 더 중요한 일에 시간을 보내기로 선택하는 것은 아닙니다.

외래 키는 데이터 를 제한 하기 위한 것 입니다. 즉, 참조 무결성을 강화합니다. 그게 다야. 다른 건 없어

1. 동일한 테이블에 여러 외래 키를 가질 수 있습니다. 발송물에 출발지와 도착지가있는 다음을 고려하십시오.

   table: USA_States
   StateID
   StateName
   
   table: Shipment
   ShipmentID
   PickupStateID Foreign key
   DeliveryStateID Foreign key

   픽업 상태에 따라 참여할 수 있습니다. 배송 상태에 참여하고 싶을 수도 있습니다. 두 가지 모두에 대해 2 개의 조인을 수행하고 싶을 수도 있습니다! SQL 엔진에는 원하는 것을 알 수있는 방법이 없습니다.

2. 종종 결합 스칼라 값을 교차합니다. 스칼라는 일반적으로 중간 계산의 결과이지만 정확한 레코드가 1 개인 특수 목적 테이블이있는 경우가 있습니다. 엔진이 조인에 대한 foriegn 키를 감지하려고 시도한 경우 ... 크로스 조인이 열과 일치하지 않기 때문에 의미가 없습니다.

3. 특별한 경우에는 둘 다 고유하지 않은 열을 결합합니다. 따라서 해당 열에 PK / FK가 존재하는 것은 불가능합니다.

4. 당신은 질문이있는 경우에 대해 때문에 포인트 2, 3 위 관련이없는 생각 입니다 테이블 사이에 하나의 PK / FK 관계. 그러나 테이블 사이에 단일 PK / FK가 있다고해서 PK / FK 외에 다른 필드를 조인 할 수는 없습니다. SQL 엔진은 어떤 필드에 가입 시킬지 알 수 없습니다.

5. "USA_States"테이블과 FK가있는 5 개의 다른 테이블이 있다고 가정하겠습니다. "5"테이블에는 서로에 대한 외부 키도 있습니다. SQL 엔진이 "USA_States"와 "five"테이블을 자동으로 결합해야합니까? 아니면 "5"를 서로 연결해야합니까? 양자 모두? SQL 엔진이 서로 연결하려고 무한 루프에 들어가도록 관계를 설정할 수 있습니다. 이 상황에서 SQL 엔진이 원하는 것을 추측하는 것은 불가능합니다.

요약 : PK / FK는 테이블 조인과 관련이 없습니다. 그것들은 별개의 무관 한 것입니다. PK / FK 컬럼에서 종종 결합하는 것은 단지 우연의 사고입니다.

SQL 엔진이 전체, 왼쪽, 오른쪽 또는 내부 조인인지 추측하도록 하시겠습니까? 나는 그렇게 생각하지 않습니다. 비록 그것이 결합 할 열을 추측하는 것보다 더 적은 죄일 것입니다.

"결합 성"의 개념. 관계 r1와 r2같은 이름을 가진 속성이 동일한 유형 인 경우에만 ...이 개념은 같은 있지만뿐만 아니라 [같은 노동 조합과 같은 다양한 다른 작업에 참여하지에만 적용되는 경우 조인입니다.

SQL 및 관계 이론 : CJ 날짜별로 정확한 SQL 코드 작성 방법

표준 SQL에는 이미로 알려진 기능 NATURAL JOIN이 있으며 mySQL에서 구현되었습니다.

당신의 제안은 그만한 가치가 없지만, 그것은 합리적인 것 같습니다. 에 대한 지원NATURAL JOIN 이 없는 SQL Server 에서는 Management Studio에서 SQL Prompt를 사용 INNER JOIN합니다 .InteliSense를 작성할 때 ON공통 속성 이름과 외래 키를 기반으로 절을 제안 할 때 매우 유용합니다. 그러나 이것에 대한 새로운 (표준) SQL 조인 유형을보고 싶지 않습니다.

SQL이 먼저왔다!

외래 키 및 외래 키 제약 조건은 나중에 나타 났으며 본질적으로 "트랜잭션"스타일 응용 프로그램에 대한 최적화입니다.

관계형 데이터베이스는 원래 관계형 대수를 사용하여 수학적으로 증명할 수 있는 방식으로 데이터 집합에 복잡한 쿼리를 적용하는 방법으로 고안되었습니다 . 주어진 데이터 세트와 주어진 쿼리에 대한 IE에는 항상 하나의 정답이 있습니다.

그 이후로 관계형 데이터베이스는 먼 길을 갔으며 트랜잭션 시스템의 지속성 계층으로 주로 사용 된 것은 CODD가 아니 었습니다. 모두 상상했다.

그러나 모든 상충되는 목표와 공급 업체 정치에 대한 ANSI 표준 본문은 항상 SQL의 "수학적으로 입증 가능한"속성을 보존하기 위해 노력해 왔습니다.

데이터베이스가 "숨겨진"외래 키 데이터에서 조인 속성을 유추하도록 허용 한 경우이 속성을 잃게됩니다 (외래 키 집합이 둘 이상 정의되어 있으면 모호성을 고려하십시오).

또한 SQL을 읽는 프로그래머는 두 테이블에 대해 현재 정의 된 외래 키를 반드시 알 필요는 없으며 쿼리가 수행 한 작업을 수행하기 위해 데이터베이스 스키마를 조사해야합니다.

외래 키 관계를 정의했지만 이것이 모든 쿼리에서 테이블을 조인하려는 방식은 아닙니다. 테이블을 조인하는 가장 가능성이 높은 방법이지만 올바르지 않은 경우가 있습니다.

• 어떤 목적으로 두 테이블 또는 그 일부의 카티 전 곱을 사용할 수 있습니다.
• 다른 목적으로 가입 할 수있는 다른 필드가있을 수 있습니다.
• 세 개 이상의 테이블을 조인하는 경우 테이블 중 하나가 두 개 이상의 테이블과 관련 될 수 있습니다. 이 경우 일반적으로 가능한 FK 관계 중 하나만 쿼리에 적합 할 수 있습니다.

당신은 잘못된 가정을 운영하고있을 수 있습니다. '발견 할 수있는 한'이라고 말하지만 경험적이거나 증거적인 증거는 제공하지 않습니다. pk 또는 fk가 쿼리에 가장 적합한 인덱스 인 경우 사용됩니다. 왜 당신이 이것을보고 있는지 모르겠지만 내 추측은 잘못 구성된 쿼리입니다.

질문이 완전히 다시 작성되었으므로 지금 편집하십시오. 설명하는 사례는 매우 작은 쿼리 집합에만 해당됩니다. 12 개의 테이블이 조인되면 어떻게됩니까? FK가 없으면 어떻게해야합니까? ... 기본 조인이 있어도 가독성을 위해 항상 조인을 지정합니다. (데이터를보고 나서 무엇이 결합되고 있는지 파악하고 싶지는 않습니다)

일부 쿼리 도구는 실제로 자동 조인을 수행 한 다음 조인을 제거하거나 편집 할 수 있습니다. MS Access의 Query Builder 가이 작업을 수행한다고 생각합니다.

마지막으로 ANSII 표준은 조인을 지정해야한다고 명시하고 있습니다. 그것이 그것을 허용하지 않을만큼 충분한 이유입니다.

외래 키를 추가 / 제거하면 응용 프로그램의 소스 코드에있는 쿼리를 포함하여 미리 작성된 쿼리의 의미가 변경된다는 사실을 포함 하여 데이터베이스 가이를 안전하게 수행 할 수없는 여러 가지 이유 가 있습니다. 또한 대부분의 데이터베이스에는 원하는 모든 조인을 포괄하는 적절한 외래 키 집합이 없습니다. 또한 더 나은 또는 가치를 위해 외래 키는 종종 시스템 속도를 높이기 위해 제거되어 파일에서 "잘못된"순서로로드 된 테이블에는 사용할 수 없습니다.

그러나 쿼리 디자인 할 이유가 없다 도구 또는 텍스트 편집기 자동은 그들이 당신을 줄 같은 방법으로 외래 키의 도움으로 가입 완료 할 수 없습니다 인텔리 열 이름은. 도구가 잘못한 경우 쿼리를 편집하고 완전히 정의 된 쿼리를 저장할 수 있습니다. 이러한 도구는 또한“부모”테이블 이름과 부모 / 자식 테이블 등에서 같은 이름을 가진 열로 외래 키 열 명명 규칙을 유용하게 사용할 수 있습니다.

(아내는 여전히 Management Studio와 Sql Server의 차이점을 이해할 수 없으며 Management Studio를 시작할 때 SQL Server 시작에 대해 이야기합니다!)

자연 조인 "자동"조인은 공통 열의 동등성을 조인하지만 테이블 의미와 원하는 결과를 기반으로 원하는 경우에만 작성해야합니다 . 두 테이블이 어떻게 "조인되어야"하는지 또는 다른 방법으로 "테이블"이 쿼리에 나타나는지 알 수있는 "자동"기능은 없습니다. 쿼리 할 제약 조건을 알 필요는 없습니다. 그것들의 존재는 단지 입력이 제한되어 결과적으로 출력도 제한 될 수 있음을 의미합니다. 선언 된 제약 조건에 따라 "자동으로"조인하는 일종의 join_on_fk_to_pk 연산자를 정의 할 수 있습니다. 당신은 단지 제약이 테이블 의미를 변경할 수 있지만 경우에 동일하게 유지하기 위해 쿼리의 의미를 원한다면하지만 당신은 할 해당 쿼리 변경해야 할 것 없는 새로운 선언 constaints을 사용합니다.제약 조건 변경에도 불구하고 이미 의미를 그대로 둡니다 .

PK, FK, UNIQUE & CHECK를 포함한 제약 조건은 테이블의 의미에 영향을 미치지 않습니다. 물론 테이블의 의미가 바뀌면 금기 사항이 바뀔 수 있습니다. 그러나 제약 조건이 변경되었다고해서 쿼리가 변경되어야한다는 의미는 아닙니다.

쿼리 할 제약 조건을 알 필요는 없습니다. 제약 조건을 알면 제약 조건을 유지하지 않으면 동일한 대답을 반환하지 않는 추가 표현식을 사용할 수 있습니다. 예를 들어 UNIQUE를 통해 테이블에 하나의 행이 있으므로 스칼라로 사용할 수 있습니다. 제약 조건이 가정되었지만 선언되지 않은 경우 이러한 쿼리가 중단 될 수 있습니다. 그러나 쿼리가 가정하지 않은 제약 조건을 선언하면 쿼리를 중단 할 수 없습니다.

사람이 읽을 수있는 설명으로부터 SQL 쿼리를 구성하는 경험 법칙이 있습니까?

그 이유는 LANGUAGE가 있고 그 뒤에 기본 주체가 있기 때문입니다. 이 언어는 드문 편이며 범용 언어로 볼 수있는 많은 기능이 부족합니다. 이것은 단순히 언어에 추가되지 않았으며 아마도 그렇지 않을 훌륭한 기능입니다. 죽은 언어는 아니므로 희망이 있지만 낙관적이지는 않습니다.

다른 사람들이 지적했듯이 일부 구현에서는 공통 열 이름을 기반으로 조인 (열)이 두 테이블을 조인하는 확장을 사용합니다. 이는 다소 비슷합니다. 그러나 널리 퍼지지는 않습니다. 이 확장은 SELECT * FROM employee NATURAL JOIN department;사용할 열을 지정하는 방법이 포함되지 않은 구문 과 다릅니다 . 또한 테이블 간의 관계에 의존하여 테이블을 신뢰할 수 없게 만듭니다 (확장자보다 자연스러운 조인 구문 이상).

PKFK가 "두 테이블간에 정의 된 외래 키 관계"를 의미하는 키워드 인 "PKFK의 내부 조인 테이블"에는 근본적인 장애가 없습니다. 동일한 테이블에 여러 fk에 문제가있을 수 있지만 단순히 오류가 발생할 수 있습니다. 문제는 언어를 디자인하는 사람들이 다른 언어 변경보다 a) 좋은 생각과 b) 작업하는 것이 더 좋다고 생각하는 것입니다 ...

ON 절을 생략하면 참조 무결성을 기준으로 필드를 따르는 것으로 가정하면 카티 전 곱을 어떻게 하시겠습니까?

편집 : AUTO 사용 이것의 장점은 타이핑이 적기 때문에 조인 방법이나 복잡한 조인을 기억할 필요가 없습니다. 관계가 변경되면 자동으로 처리되지만 초기 개발을 제외하고는 거의 발생하지 않습니다.

지금해야 할 일은 관계 선언 변경 중에 select 문의 의도와 일치하도록 모든 AUTO 조인을 유지할지 결정하는 것입니다.

데이터베이스에서 해당 테이블을 조인하면 pk / fk 열에서 조인하려는 이유를 알 수없는 이유는 무엇입니까?

이유의 일부는 다음과 같습니다.

1-이론적으로 두 테이블에서 임의의 열에있는 테이블을 조인 할 수 있습니다. 이것은 일반적인 관행은 아니지만 유효합니다. SQL은 프로그래밍 언어와 같으며, 물론 열 및 이름 열에 어떤 정보가 있는지 이해하지 못하므로 SQL에 대해서는 큰 의미가 없습니다.

2-다른 유형의 조인이 있습니다 (왼쪽, righ, 내부)-내부 조인은 그 중 하나입니다.

3-SQL 표준은 더 높은 수준의 방언이이를 사용하여 지능을 형성 할 수있게하는 낮은 수준의 언어라는 원칙에 따라 안내 될 수 있습니다. 4 세대 언어와 3 세대 언어를 비교하면 비교가 다소 명확 해집니다. 실제로 내가 사용한 도구 중 하나 인 IEF를 사용하면 다음과 같이 작성할 수 있습니다.

ReadEach Customer 
Where Customer Places Orders and That Customer LivesIn "California" 
and OrderValue > 100.00

요약하면 제안은 흥미롭고 표준의 일부 또는 저장 프로 시저 (기본값은 내부 조인)로 구현 될 수 있습니다.

Tiddo, 나는 당신이 완전히 옳다고 생각합니다. 그 주제에 대한 SQL은 꽤 바보입니다 . 그리고 나는 10 년 전에 SQL을 배우면서 외래 키에 대해했던 것과 똑같은 생각을 한 것을 기억합니다.

좋아, 결국 그 시험에 합격해야했다. 그리고 그것을 통과하기 위해 가야했습니다 . SQL은 누구나 인정할 수있는 것보다 난파선이되고 표준화 경로는 완전한 재앙이며 일부 구현은 협박 적으로 완료 됩니다. 여전히 일반적으로 매우 편리합니다. (나는 K / V 루디 테이트가 아니다)

외래 키라면 ... 전혀 편리하지 않습니다. 관계형 모델 에서 중요한 개념 입니다. 같은 이름 의 SQL 기능 은 잘 비교되지 않습니다.

직접 말하십시오 : 성능 문제가있는 큰 시스템에 도달 할 때까지 전혀 호출되지 않은 SQL 기능을 사용하지 마십시오Foreign Key . 명시 적으로 엔진 말하는 외래 키이며 어떤되지 않는 분야 입니다 만 색인에 사용을하고는 DB를 사용자에게 보이지입니다.

오해의 소지가 있습니까?
예.

30 년 동안 사람들을 오도 한 후 지금은 더 강력 해 질 것입니까?
기회가 없습니다.

필요할 때까지 외래 키를 완전히 무시하는 중 ... 고정 SQL?
예!

그리고 왜이 모든 일이 처음에 일어 났습니까?
음, 기능 우리는 외래 키를 호출 SQL에, 나중에 첨가 하였다 SQL은 시간이 지남에 따라 상향식으로 발전한 표준입니다. 공급 업체는 성가신 기능을 구현했으며 표준 바디는 곤경에 처했습니다.

외부 키는 색인 작성만을위한 것이며 사용 가능한 JOIN 구문이 없습니다. ( SELECT쿼리 로 수행 된 곳 에서 JOIN쿼리는 매우 최신이며 별칭 SELECT기능 만을위한 것입니다.) 아마도 해당 인덱스 플래그를 호출하는 것은 관계형 DB 이론 개념 FOREIGN KEY에 대한 영리한 이름 지정 해킹 일 것 입니다.