데이터베이스 설계에 외래 키가 정말 필요한가요?

https://stackoverflow.com/questions/18717

09-06-2019
|

문제

내가 아는 한, 외래 키(FK)는 프로그래머가 올바른 방식으로 데이터를 조작하는 데 도움을 주는 데 사용됩니다.프로그래머가 이미 올바른 방식으로 이 작업을 수행하고 있다고 가정해 보겠습니다. 그러면 외래 키 개념이 정말 필요합니까?

외래 키를 다른 용도로 사용할 수 있나요?여기서 뭔가 빠졌나요?

해결책

외래 키는 데이터 수준에서 참조 무결성을 강화하는 데 도움이 됩니다.또한 일반적으로 기본적으로 인덱싱되므로 성능도 향상됩니다.

다른 팁

외래 키는 프로그래머가 다음과 같은 것을 사용하여 코드를 적게 작성하는 데 도움이 될 수도 있습니다. ON DELETE CASCADE.즉, 사용자가 포함된 테이블 하나와 주문 등이 포함된 테이블이 있는 경우 사용자를 삭제하면 해당 사용자를 가리키는 모든 주문이 자동으로 삭제될 수 있습니다.

외래 키 없이 데이터베이스를 설계하는 것은 상상할 수 없습니다.그것들이 없으면 결국 실수를 하고 데이터의 무결성이 손상될 수밖에 없습니다.

그들은 그렇지 않다 필수의, 엄밀히 말하면 이점은 엄청납니다.

나는 그것을 확신한다. 포그버그 데이터베이스에 외래 키 제약 조건이 없습니다.나는 그것이 어떻게 이루어지는지 듣고 싶습니다. 포그 크릭 소프트웨어 팀은 불일치가 발생하지 않도록 코드를 구성합니다.

FK 제약 조건이 없는 데이터베이스 스키마는 안전벨트 없이 운전하는 것과 같습니다.

언젠가는 후회하게 될 거예요.디자인 기본 사항과 데이터 무결성에 약간의 추가 시간을 소비하지 않는 것은 나중에 골치 아픈 일을 보장하는 확실한 방법입니다.

그렇게 엉성한 애플리케이션 코드를 허용하시겠습니까?멤버 개체에 직접 액세스하고 데이터 구조를 직접 수정했습니다.

왜 이것이 어렵게 만들어졌다고 생각하는가? 심지어 받아들일 수 없는 현대 언어로?

예.

그들은 당신을 정직하게 유지합니다
그들은 새로운 개발자를 정직하게 유지합니다
넌 할 수있어 ON DELETE CASCADE
테이블 간의 링크를 자체적으로 설명하는 멋진 다이어그램을 생성하는 데 도움이 됩니다.

개인적으로 나는 테이블 간의 관계를 공식화하기 때문에 외래 키를 선호합니다.귀하의 질문은 프로그래머가 참조 무결성을 위반하는 데이터를 도입하지 않는다고 가정하고 있다는 것을 알고 있지만 최선의 의도에도 불구하고 데이터 참조 무결성이 위반되는 사례를 너무 많이 보았습니다!

사전 외래 키 제약 조건(선언적 참조 무결성 또는 DRI라고도 함)으로 인해 트리거를 사용하여 이러한 관계를 구현하는 데 많은 시간이 소요되었습니다.선언적 제약을 통해 관계를 공식화할 수 있다는 사실은 매우 강력합니다.

@John - 다른 데이터베이스는 외래 키에 대한 인덱스를 자동으로 생성할 수 있지만 SQL Server는 그렇지 않습니다.SQL Server에서 외래 키 관계는 단지 제약 조건일 뿐입니다.외래 키에 대한 인덱스를 별도로 정의해야 합니다(이것이 유익할 수 있음).

편집하다:IMO에서는 ON DELETE 또는 ON UPDATE CASCADE를 지원하기 위해 외래 키를 사용하는 것이 반드시 좋은 것은 아니라는 점을 덧붙이고 싶습니다.실제로 나는 데이터의 관계를 기반으로 삭제 시 계단식 배열을 신중하게 고려해야 한다는 것을 발견했습니다.이것이 정상일 수 있는 자연스러운 부모-자식이 있습니까? 아니면 관련 테이블이 조회 값 집합입니까?계단식 업데이트를 사용한다는 것은 한 테이블의 기본 키를 수정할 수 있음을 의미합니다.이 경우 테이블의 기본 키가 변경되어서는 안 된다는 일반적인 철학적 의견 차이가 있습니다.키는 본질적으로 일정해야 합니다.

프로그래머가 실제로 이미 올바른 방식으로 이 작업을 수행하고 있다고 가정해 보겠습니다.

그런 가정을 하는 것은 나에게는 매우 나쁜 생각인 것 같습니다.일반적으로 소프트웨어는 엄청나게 버그가 많습니다.

그리고 그것이 바로 요점입니다.개발자는 일을 제대로 할 수 없으므로 데이터베이스가 잘못된 데이터로 채워지지 않도록 하는 것은 좋은 일입니다.

이상적인 세계에서는 자연 조인이 관계를 사용합니다(예:FK 제약 조건)은 열 이름과 일치하는 것이 아닙니다.이렇게 하면 FK가 더욱 유용해집니다.

외래 키가 없으면 서로 다른 테이블의 두 레코드가 관련되어 있음을 어떻게 알 수 있습니까?

나는 당신이 언급하고 있는 것이 참조 무결성이라고 생각합니다. 즉, 기존 상위 레코드 등이 없으면 하위 레코드를 생성할 수 없습니다.이는 흔히 외래 키 제약 조건으로 알려져 있지만, 애초에 외래 키의 존재와 혼동되어서는 안 됩니다.

외래 키가 없으면 이점이 있나요?형편없는 데이터베이스를 사용하지 않는 한 FK를 설정하는 것은 그리 어렵지 않습니다.그렇다면 왜 그들을 피하는 정책을 가지겠습니까?한 열이 다른 열을 참조한다는 명명 규칙을 갖는 것과 데이터베이스가 실제로 해당 관계를 확인하고 있다는 것을 아는 것은 또 다른 문제입니다.

아마 당신이 얘기하고있는 것 같아요 데이터베이스에 의해 시행되는 외래 키 제약조건.아마도 이미 외래 키를 사용하고 있을 것입니다. 단지 이에 대해 데이터베이스에 알리지 않았을 뿐입니다.

프로그래머가 실제로 이미 올바른 방식 으로이 작업을 수행하고 있다고 가정 해 봅시다. 그렇다면 우리는 실제로 외국 열쇠의 개념이 필요합니까?

이론적으로는 그렇지 않습니다.그러나 버그가 없는 소프트웨어는 한번도 없었습니다.

애플리케이션 코드의 버그는 일반적으로 그다지 위험하지 않습니다. 버그를 식별하고 수정하면 애플리케이션이 다시 원활하게 실행됩니다.그러나 버그로 인해 손상된 데이터가 데이터베이스에 들어갈 수 있다면 문제가 발생하는 것입니다!데이터베이스의 손상된 데이터를 복구하는 것은 매우 어렵습니다.

미묘한 버그가 있는지 고려하십시오. 포그버그 손상된 외래 키가 데이터베이스에 기록되도록 허용했습니다.버그를 수정하고 버그 수정 릴리스를 통해 고객에게 수정 사항을 신속하게 전달하는 것은 쉬울 수 있습니다.그런데 수십 개의 데이터베이스에 있는 손상된 데이터를 어떻게 수정해야 할까요? 옳은 이제 외래 키의 무결성에 대한 가정이 더 이상 유지되지 않기 때문에 코드가 갑자기 중단될 수 있습니다.

웹 애플리케이션에서는 일반적으로 데이터베이스와 통신하는 프로그램이 하나만 있으므로 버그로 인해 데이터가 손상될 수 있는 곳은 한 곳뿐입니다.엔터프라이즈 애플리케이션에는 동일한 데이터베이스와 통신하는 여러 개의 독립적인 애플리케이션이 있을 수 있습니다(데이터베이스 쉘로 직접 작업하는 사람들은 말할 것도 없습니다).모든 애플리케이션이 버그 없이 항상 그리고 영원히 동일한 가정을 따르는지 확인할 수 있는 방법은 없습니다.

제약 조건이 데이터베이스에 인코딩된 경우 버그로 인해 발생할 수 있는 최악의 상황은 사용자에게 일부 버그에 대한 추악한 오류 메시지가 표시되는 것입니다. SQL 제약 조건이 충족되지 않았습니다.이것은 많이 손상된 데이터를 엔터프라이즈 데이터베이스에 놔두는 것이 더 좋습니다. 그러면 모든 애플리케이션이 중단되거나 모든 종류의 잘못되거나 오해의 소지가 있는 출력이 발생하게 됩니다.

아, 그리고 외래 키 제약 조건은 기본적으로 인덱싱되므로 성능도 향상시킵니다.아무 이유도 생각이 안 나 ~ 아니다 외래 키 제약 조건을 사용합니다.

FK는 매우 중요하며 항상 스키마에 존재해야 합니다. 당신이 이베이가 아니라면.

제 생각에는 뭔가 하나 어느 시점에서는 유효한 관계를 보장할 책임이 있어야 합니다.

예를 들어, 루비 온 레일즈 외래 키를 사용하지 않지만 모든 관계 자체의 유효성을 검사합니다.Ruby on Rails 애플리케이션에서만 데이터베이스에 액세스하는 경우에는 괜찮습니다.

그러나 데이터베이스에 쓰는 다른 클라이언트가 있는 경우 외래 키 없이 자체 유효성 검사를 구현해야 합니다.그런 다음 프로그래머라면 누구나 이것이 심각한 죄라고 말할 수 있을 가능성이 가장 높은 두 개의 유효성 검사 코드 복사본을 갖게 됩니다.

이 시점에서 외래 키를 사용하면 책임을 다시 단일 지점으로 이동할 수 있으므로 외래 키가 실제로 필요합니다.

외래 키를 사용하면 이전에 데이터베이스를 본 적이 없는 사람이 테이블 간의 관계를 확인할 수 있습니다.

지금은 모든 것이 괜찮을지 모르지만, 프로그래머가 떠나고 다른 사람이 그 자리를 대신하게 되면 어떤 일이 일어날지 생각해 보십시오.

외래 키를 사용하면 수천 줄의 코드를 검색하지 않고도 데이터베이스 구조를 이해할 수 있습니다.

내가 아는 한, 외래 키는 프로그래머가 데이터를 올바른 방식으로 조작하는 데 도움을 주는 데 사용됩니다.

FK를 사용하면 프로그래머가 작업을 수행할 때 DBA가 사용자의 실수로부터 데이터 무결성을 보호할 수 있습니다. 실패하다 그렇게 하기 위해, 때로는 프로그래머의 실수로부터 보호하기 위해.

프로그래머가 이미 올바른 방식으로 이 작업을 수행하고 있다고 가정해 보겠습니다. 그러면 외래 키 개념이 정말 필요합니까?

프로그래머는 죽기 쉽고 오류가 있습니다.FK는 선언적 그래서 망치기가 더 어려워집니다.

외래 키를 다른 용도로 사용할 수 있나요?여기서 뭔가 빠졌나요?

이것이 FK가 만들어진 이유는 아니지만 FK는 다이어그램 도구와 쿼리 빌더에 강력하고 신뢰할 수 있는 힌트를 제공합니다.이는 강력하고 신뢰할 수 있는 힌트가 절실히 필요한 최종 사용자에게 전달됩니다.

안전벨트가 꼭 필요하지 않은 것처럼 그것들도 꼭 필요한 것은 아닙니다.하지만 데이터베이스를 엉망으로 만드는 어리석은 일을 하지 않도록 도와줄 수 있습니다.

애플리케이션을 중단시킨 삭제 항목을 재구성하는 것보다 FK 제약 조건 오류를 디버깅하는 것이 훨씬 더 좋습니다.

이는 애플리케이션이 데이터베이스에서 데이터를 조작할 수 있는 유일한 방법이 아니기 때문에 중요합니다.귀하의 애플리케이션은 원하는 만큼 정직하게 참조 무결성을 처리할 수 있지만 데이터베이스 수준에서 삽입, 삭제 또는 업데이트 명령을 실행하고 실행할 수 있는 올바른 권한을 가진 보조자 한 명만 있으면 모든 애플리케이션 참조 무결성 적용이 우회됩니다.데이터베이스 수준에서 FK 제약 조건을 적용한다는 것은 이 바보가 명령을 실행하기 전에 FK 제약 조건을 비활성화하도록 선택하지 않으면 FK 제약 조건으로 인해 참조 무결성 위반으로 인해 잘못된 삽입/업데이트/삭제 문이 실패하게 된다는 의미입니다.

비용/편익 측면에서 생각해보면...~ 안에 MySQL, 제약 조건을 추가하는 것은 DDL.그것은 단지 몇 개의 핵심 단어와 몇 초의 생각일 뿐입니다.제가 생각하는 유일한 "비용"은...

도구는 외래 키를 좋아합니다.외래 키는 비즈니스 논리나 기능에 영향을 주지 않아 눈에 띄지 않고 축적될 수 있는 잘못된 데이터(즉, 분리된 행)를 방지합니다.또한 스키마에 익숙하지 않은 개발자가 관계가 누락되었다는 사실을 깨닫지 못한 채 전체 작업 덩어리를 구현하는 것을 방지합니다.아마도 현재 애플리케이션의 범위 내에서는 모든 것이 훌륭할 수도 있지만, 뭔가를 놓쳤고 언젠가 예상치 못한 것이 추가된다면(멋진 보고를 생각해보세요) 처음부터 누적되어 온 잘못된 데이터를 수동으로 정리해야 하는 상황에 처하게 될 수도 있습니다. 데이터베이스 강제 검사 없이 스키마를 삭제합니다.

당신이 일을 정리할 때 이미 머리 속에 있는 것을 성문화하는 데 약간의 시간이 걸리면 당신이나 다른 사람이 앞으로 몇 달 또는 몇 년의 슬픔을 겪지 않게 할 수 있습니다.

질문:

외국 키에 대한 다른 용도가 있습니까?여기서 뭔가 빠졌나요?

조금로드되었습니다."외부 키" 대신 주석, 들여쓰기 또는 변수 이름 삽입...문제의 내용을 이미 완벽하게 이해했다면 그것은 "소용이 없습니다".

엔트로피 감소.데이터베이스에서 혼란스러운 시나리오가 발생할 가능성을 줄입니다.모든 가능성을 고려하기 때문에 어려움을 겪고 있습니다. 따라서 제 생각에는 엔트로피 감소가 모든 시스템 유지 관리의 핵심입니다.

예를 들어 가정을 하면 다음과 같습니다.각 주문에는 가정이 시행되어야 하는 고객이 있습니다. 무엇.데이터베이스에서 "무언가"는 외래 키입니다.

나는 이것이 개발 속도의 균형을 이룰 가치가 있다고 생각합니다.물론, 이 기능을 끄면 더 빠르게 코딩할 수 있으며 이것이 아마도 일부 사람들이 사용하지 않는 이유일 것입니다.개인적으로 나는 많은 시간을 죽였습니다. NH절전 모드 그리고 어떤 작업을 수행할 때 화를 내는 외래 키 제약 조건도 있습니다.그러나 문제가 무엇인지 알고 있으므로 문제가 덜합니다.저는 일반 도구를 사용하고 있으며 이 문제를 해결하는 데 도움이 되는 리소스가 있습니다. 어쩌면 사람들이 도와줄 수도 있습니다!

대안은 외래 키가 설정되지 않고 데이터가 일관되지 않는 시스템에 버그가 침투하도록 허용하는 것입니다(충분한 시간이 주어지면 그렇게 될 것입니다).그런 다음 특이한 버그 보고서를 받고 조사한 후 "오"합니다.데이터베이스가 망가졌습니다.이제 문제를 해결하는 데 얼마나 걸릴까요?

외래 키를 다음과 같은 제약 조건으로 볼 수 있습니다.

데이터 무결성 유지 지원
데이터가 서로 어떻게 관련되어 있는지 보여줍니다(비즈니스 논리 및 규칙을 적용하는 데 도움이 될 수 있음).
올바르게 사용하면 테이블에서 데이터를 가져오는 효율성을 높이는 데 도움이 될 수 있습니다.

현재는 외래 키를 사용하지 않습니다.그리고 대부분의 경우 우리는 그것을 후회하지 않습니다.

그렇긴 하지만, 우리는 여러 가지 이유로 가까운 미래에 이 기능을 훨씬 더 많이 사용하게 될 것입니다. 둘 다 비슷한 이유입니다.

다이어그램 작성.외래 키 관계가 올바르게 사용되면 데이터베이스 다이어그램을 생성하는 것이 훨씬 쉽습니다.
도구 지원.다음을 사용하여 데이터 모델을 구축하는 것이 훨씬 쉽습니다. 비주얼 스튜디오 2008 다음 용도로 사용할 수 있는 것 LINQ에서 SQL로 적절한 외래 키 관계가 있는 경우.

따라서 내 요점은 우리가 많은 수동 SQL 작업(쿼리 구성, 쿼리 실행, 어쩌구 저쩌고)을 수행하는 경우 외래 키가 반드시 필수적인 것은 아니라는 점을 발견했다는 것입니다.하지만 일단 도구를 사용하기 시작하면 훨씬 더 유용해집니다.

외래 키 제약 조건(및 일반적으로 제약 조건)의 가장 좋은 점은 쿼리를 작성할 때 이를 사용할 수 있다는 것입니다."true"를 유지하는 데이터 모델을 신뢰할 수 없으면 많은 쿼리가 훨씬 더 복잡해질 수 있습니다.

코드에서는 일반적으로 어딘가에서 예외가 발생합니다. SQL, 우리는 일반적으로 "잘못된" 답변을 얻게 됩니다.

이론에 의하면, SQL 서버 쿼리 계획의 일부로 제약 조건을 사용할 수 있지만 파티셔닝에 대한 검사 제약 조건을 제외하고는 실제로 그런 현상을 목격했다고 말할 수 없습니다.

내가 작업한 프로젝트(비즈니스 애플리케이션 및 소셜 네트워킹 웹사이트)에서 외래 키가 명시적으로 선언된 적이 없습니다(외래 키 참조 테이블(열)).

그러나 항상 외래 키인 열 이름을 지정하는 일종의 관례가 있었습니다.

그것은 마치 데이터베이스 정규화 -- 당신은 무엇을 하고 있는지, 그리고 그 결과는 무엇인지 알아야 합니다(주로 성능).

나는 외래 키의 장점(데이터 무결성, 외래 키 열에 대한 인덱스, 데이터베이스 스키마를 인식하는 도구)을 알고 있지만 외래 키를 일반적인 규칙으로 사용하는 것이 두렵습니다.

또한 다양한 데이터베이스 엔진이 다른 방식으로 외래 키를 제공할 수 있으며, 이로 인해 마이그레이션 중에 미묘한 버그가 발생할 수 있습니다.

ON DELETE CASCADE를 사용하여 삭제된 클라이언트의 모든 주문과 송장을 제거하는 것은 보기에는 좋지만 잘못 설계된 데이터베이스 스키마의 완벽한 예입니다.

예.ON DELETE [RESTRICT|CASCADE]는 개발자가 데이터를 묶어두는 것을 방지하여 데이터를 깔끔하게 유지합니다.저는 최근 외래 키와 같은 데이터베이스 제약 조건에 중점을 두지 않는 Rails 개발자 팀에 합류했습니다.

운 좋게도 다음을 찾았습니다. http://www.redhillonrails.org/foreign_key_associations.html -- Ruby on Rails 플러그인의 RedHill은 다음을 사용하여 외래 키를 생성합니다. 구성에 대한 관례 스타일.다음을 사용한 마이그레이션 제품 ID 에 대한 외래 키를 생성합니다. ID 에서 제품 테이블.

다른 훌륭한 플러그인을 확인해 보세요. 붉은 언덕, 트랜잭션으로 래핑된 마이그레이션을 포함합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow