왜 키를 명시해야합니까?

15

나는 데이터베이스의 주제에 대해 매우 익숙하지 않으므로 무지하게 들릴 수 있지만 키가 테이블 내에서 명시되어야하는 이유가 궁금합니다. 이것은 주로 주어진 열 값이 각 행 내에서 고유해야한다는 것을 사용자에게 알리는 것입니까? 언급되지 않더라도 독창성은 여전히 존재해야합니다.

primary-key unique-constraint

— dsaxton
소스

UNIQUE 키가 있다면 왜 PRIMARY 키를 가지고 귀찮게합니까?

— Vérace

1

왜 그들은 전혀 선언되지 않았습니까? 매우 도움이되는 것처럼 보이지만 실제로 작동하는 데이터베이스가 필요합니까?

— dsaxton

1

데이터베이스가 작동하는 데 필요하지는 않지만 데이터 가 "작동" 하기 위해 필요합니다. 즉, 일관성을 유지해야 합니다. 이는 데이터베이스 서버에 정보의 일관성 을 유지 하도록 지시하는 방식과 정확히 일치하기 때문입니다 .

— Andriy M

데이터베이스 가 주어진 필드가 키라는 것을 알고 있으면 부작용은 키를 포함하는 행을 테이블의 모든 행을 살펴 보는 것보다 훨씬 빠르게 찾을 수 있다는 것입니다. 인덱스는 데이터베이스가 유용한 이유 중 매우 중요한 부분입니다.

— Thorbjørn Ravn Andersen

32

CONSTRAINT데이터베이스의 s가 해당 데이터베이스에 액세스하는 응용 프로그램에 의해 적용되어야 함을 분명히 제안하고 있습니까?

이것이 나쁜 (나쁜, 나쁜 ...) 생각 인 이유 는 여러 가지 가 있습니다 .

1) "자신의 롤 (roll-your-own)"제약 조건 "엔진"(즉, 애플리케이션 코드 내)을 구축하는 경우 Oracle / SQL Server / MySQL / PostgreSQL / <. whoever ...>가 소비 한 것을 모방하는 것입니다. 몇 년 동안 . CONSTRAINT 코드는 그 동안 수백만 명의 최종 사용자에 의해 테스트되었습니다 .

2) 당신과 당신의 팀에 대한 모든 존중과 함께, 당신은 몇 년 안에조차도 그것을 얻지 못할 것입니다- 여기 에서 MySQL 코드 만 4 천만 달러가 들었습니다. 그리고 MySQL은 위 3 대의 서버 중 가장 저렴하며 CHECK CONSTRAINT도 구현하지 않습니다. 분명히 RI (참조 무결성)를 올바르게 얻는 것은 어렵습니다.

필자는 Oracle 포럼을 자주 사용했으며 일부 가난한 관리자 / 프로그래머가 이전에 자신의 직무를 맡았던 천재가 제안한 일을하는 "밝은"아이디어를 가지고 있었던 프로젝트를 그에게 맡겼던 횟수를 알 수 없습니다. .

Jonathan Lewis ( Oracle optimiser 의 기본 사항에 대한 550 페이지의 책을 썼습니다 )는 그렇지 않습니다. 다른 책에서 그의 디자인 재해 2 명 ( " Tales of the Oak Table "-Oak Table은 Oracle 전문가 그룹 임)

Oracle의 제약 조건 확인 기능을 활용하는 대신 애플리케이션 수준에서 데이터 무결성을 검사합니다.

3) 기적에 의해 RI를 올바르게 구현할 수 있더라도 해당 데이터베이스에 닿는 모든 응용 프로그램에 대해 RI 를 몇 번이고 완전히 다시 구현해야합니다. 데이터가 중요한 경우 새 응용 프로그램이 필요합니다. 이것을 패러다임으로 선택하면 여러분과 동료 프로그래머 (지원 직원 및 영업 담당자는 말할 것도없고)가 지속적인 소방과 불행의 삶으로 이어질 것입니다.

애플리케이션 레벨에서 데이터 CONSTRAINT를 구현하는 것이 여기 , 여기 및 여기에 열광적 인 이유에 대해 더 자세히 읽을 수 있습니다 .

질문에 구체적으로 답변하려면 :

왜 그들은 전혀 선언되지 않았습니까? 매우 도움이되는 것처럼 보이지만 실제로 작동하는 데이터베이스가 있어야합니다.

하는 이유 KEY들 (중 PRIMARY, FOREIGN, UNIQUE아니면 그냥 일반 INDEX이 상태에서 ES가) 선언, 즉이다 엄격하지 그 기능에 대한 데이터베이스를 가질 필요가있다, 절대적으로 그들을 함수에 대한 선언 할 필요 도 .

— 베라
소스

1

답변 주셔서 감사합니다. 나는 그것을 완전히 이해하기 위해 더 많은 것을 배울 필요가있을 것이다. (실제로 팀에 속하지 않고 호기심에서 데이터베이스에 대해서만 배우고 있습니다.)

— dsaxton

2

몇 가지 책 (Date, Garcia-Molina ...)을 읽고 특정 질문 이있는 경우 저희에게 다시 오십시오 (과도하게 광범위한 질문은 여기서 논외 주제로 간주 됨). ps 포럼에 오신 것을 환영합니다 :-)

— Vérace

내가 지금까지 당신은 넣지 제안 절대 동안 어떤 데이터베이스에 제약을 당신이 (서비스 지향 아키텍처 모든 응용 프로그램 공유 서비스에서 소비함으로써 # 3을 피할 수, (당신은 항상 최소한의 기본 키와 외래 키가 있어야합니다) ). (어쨌든 데이터베이스에서 필요한 모든 마지막 무결성 검사를 수행하면 악몽을

— 겪을

10

데이터베이스에서 키를 작성할 때 DBMS 엔진은 키 속성에 고유 제한 조건을 적용합니다. 이것은 적어도 세 가지 관련 목적을 제공합니다.

데이터 무결성 : 중복 데이터는 주요 속성에 입력 할 수 없습니다. 따라서 키에 대한 모든 종속성이 보장됩니다.
식별 : 사용자는 데이터를 정확하게 식별하고 업데이트하는 수단으로 키를 사용할 수 있습니다.
최적화 : 고유 한 속성에 대한 정보 (메타 데이터)를 DBMS 쿼리 최적화 프로그램에서 사용할 수 있습니다. 이 정보를 통해 옵티마이 저는 특정 방식으로 쿼리 실행을 단순화하여 쿼리가 더 빠르게 실행될 수 있습니다.

— 엔 보겔
소스

8

기존의 우수 답변에 한 가지 측면을 추가하겠습니다 : 문서. 엔터티를 식별하는 데 사용할 수있는 키 종류를 확인하는 것이 중요합니다. 고유 한 열 조합은 후보 키입니다.

기본 키는 실제로 유용한 개념 인 경향이 있습니다.

키를 적용할지 여부에 관계없이 설명서는 가치가 있습니다.

— boot4life
소스

1

데이터베이스 다이어그램! 내가 익숙하지 않은 소프트웨어에 대해 의미있는 말을 할 때 항상 가장 먼저하는 일은 관계형 데이터베이스를 사용하는지 확인하고, 그렇지 않은 경우 데이터베이스 다이어그램을 작성하는 것입니다. 그것은 응용 프로그램이 작동하는 정보에 대한 훌륭한 아이디어를 줄 것입니다. 불행히도 내가 본 데이터베이스의 90 %가 외래 키를 선언하지 않으므로 다이어그램은 테이블 세트 일뿐입니다. 암시 적 응용 프로그램 수준 외래 키를 추론 하려면 추측과 조정이 필요합니다.

— reinierpost

1

@reinierpost 전적으로 동의합니다. 데이터는 영구적으로 유지되므로 문서를 작성하고 깨끗하게 유지하는 가장 중요한 개체입니다. 코드는 변경 될 수 있습니다. 더 일시적인 경향이 있습니다.

— boot4life

@reinierpost- 대 유럽 국가의 철도 인프라 전체 에 소프트웨어를 공급 한 회사 (대수- 수십억 개의 위젯)에 문의 한 후 "음, 나는 FOREIGN KEY정의를 확인하기 위해 쿼리를 실행합니다 . 시스템에 대한 느낌 ". 내 쿼리가 zip을 반환했습니다 !!! 내 SQL이 잘못되었을 것이므로 수석 프로그래머 중 한 사람에게 이것을 언급했습니다. 그는 자부심을 가지고 (신생아를 제시하는 것처럼) "모든 수색이 PRIMARY KEYs" 에 있기 때문에 시스템에 FK가 없다고 발표했습니다 . <호 ...> 라 호머 심슨!

— Vérace 2016 년

5

내부 애플리케이션 코드 대신 CONSTRAINT를 사용해야하는 또 다른 이유는 다음과 같습니다.

개발자 / dba가 insert / update / delete 문을 사용하여 DB에서 직접 데이터를 수정하면 어떻게됩니까? 이 경우 모든 훌륭한 응용 프로그램 기반의 참조 무결성은 쓸모가 없습니다. 나는 어떤 개발자들은 적어도 자신이 무엇을하는지 알고 있기 때문에 RI를 방해하지 않고 직접 데이터를 수정할 수있는 가능성을 알고있다.

추신 : 물론 트리거를 만들 수는 있지만 일반적으로 속도가 느립니다 (CONSTRAINTS와 비교).

— 토마스 프란츠
소스