데이터베이스 설계에 외부 키가 정말 필요합니까?

데이터베이스 설계에 외부 키가 정말 필요합니까?

제가 알기로는 외부 키(FK)는 프로그래머가 데이터를 올바르게 조작하는 데 도움이 됩니다.프로그래머가 이미 올바른 방법으로 이 작업을 수행하고 있다고 가정하면, 외래 키의 개념이 정말 필요한 것일까요?

다른 외부 키 용도가 있나요?내가 뭘 빠트렸나요?

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

키는 가 코드 수 .ON DELETE CASCADE과 주문이 이 1개 경우 될 수

외부 키 없이 데이터베이스를 설계하는 것은 상상할 수 없다.이러한 정보가 없으면 결국 실수하여 데이터의 무결성을 손상시킬 수밖에 없습니다.

엄밀히 말하면 꼭 필요한 것은 아니지만, 큰 메리트를 얻을 수 있습니다.

FogBugz는 데이터베이스에 외부 키 제약이 없는 것이 확실합니다.Fog Creek Software 팀이 어떻게 코드를 구성해서 부정합이 발생하지 않도록 하는지 알고 싶습니다.

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

언젠가는 후회할 거예요.설계의 기초와 데이터의 정합성에 시간을 들이지 않는 것이, 장래의 골칫거리를 확실히 해소할 수 있는 그대로입니다.

그렇게 엉성한 코드를 당신의 신청서에 받아주시겠습니까?멤버 오브젝트에 직접 액세스하여 데이터 구조를 직접 수정했습니다.

당신은 왜 이것이 현대 언어에서 어렵게 만들어졌다고 생각하나요?

네.

1. 그들은 당신을 정직하게 유지시켜준다.
2. 신규 개발자를 정직하게 유지하다
3. 수 있다ON DELETE CASCADE
4. 테이블 간의 링크를 스스로 설명하는 멋진 다이어그램을 생성하는 데 도움이 됩니다.

프로그래머가 실제로 이미 올바른 방법으로 이 작업을 수행하고 있다고 가정합니다.

그런 추측을 하는 것은 나에게 매우 나쁜 생각인 것 같다; 일반적으로 소프트웨어는 매우 복잡하다.

그게 바로 요점이야, 정말로.개발자는 문제를 해결할 수 없기 때문에 데이터베이스가 잘못된 데이터로 채워지지 않도록 하는 것이 좋습니다.

이상적인 세계에서는 자연 조인은 열 이름과 일치하는 대신 관계(FK 제약 조건)를 사용한다.이것은 FK를 훨씬 더 유용하게 만들 것이다.

개인적으로, 나는 외래 키가 테이블 간의 관계를 공식화하기 때문에 외래 키에 찬성한다.당신의 질문은 프로그래머가 참조 무결성을 위반할 수 있는 데이터를 도입하지 않는다는 것을 전제로 하고 있다는 것을 알고 있습니다만, 좋은 의도에도 불구하고 데이터 참조 무결성이 침해되는 사례는 너무 많습니다.

외부 키 이전의 제약 조건(DRI(Declarative Reference Integrity, 선언적 참조 무결성))은 트리거를 사용하여 이러한 관계를 구현하는 데 많은 시간이 소요되었습니다.선언적 제약에 의해 관계를 공식화할 수 있다는 사실은 매우 강력합니다.

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

편집: IMO를 추가하고 싶습니다만, ON DELETE 또는 ON UPDATE CASCADE를 지원하는 외부 키를 사용하는 것이 반드시 좋은 것은 아닙니다.실제로 삭제 시 캐스케이드는 데이터의 관계에 따라 신중하게 검토해야 한다는 것을 알게 되었습니다.예를 들어, 이것이 정상일 가능성이 있는 자연스러운 부모-자녀가 있는지, 또는 관련 테이블이 룩업 값 세트인지 등입니다.캐스케이드된 업데이트를 사용하면 1개의 테이블의 프라이머리 키를 변경할 수 있습니다.이 경우 테이블의 기본 키가 바뀌어서는 안 된다는 점에서 일반적인 철학적인 의견 차이가 있습니다.키는 본질적으로 일정해야 합니다.

외부 키가 없는 경우 서로 다른 테이블의 두 레코드가 관련이 있는지 어떻게 알 수 있습니까?

당신이 말하는 것은 기존의 부모 레코드 등이 없으면 자녀 레코드가 생성될 수 없는 참조 무결성이라고 생각합니다.이는 종종 외부 키 제약사항으로 알려져 있지만 애초에 외부 키의 존재와 혼동해서는 안 됩니다.

데이터베이스에 의해 강제된 외부 키 제약에 대해 말씀하시는 것 같습니다.이미 외부 키를 사용하고 있을 가능성이 높지만 데이터베이스에 알리지 않았을 뿐입니다.

프로그래머가 이미 올바른 방법으로 이 작업을 수행하고 있다고 가정하면, 외래 키의 개념이 정말 필요한 것일까요?

이론상으로는 안 돼하지만 버그가 없는 소프트웨어는 없었습니다.

애플리케이션 코드의 버그는 일반적으로 그다지 위험하지 않습니다. 버그를 특정하여 수정하면 애플리케이션이 다시 원활하게 실행됩니다.그러나 버그로 인해 손상된 데이터가 데이터베이스로 유입될 수 있는 경우에는 오류가 발생합니다.데이터베이스의 손상된 데이터를 복구하는 것은 매우 어렵습니다.

FogBugz의 미묘한 버그로 인해 손상된 외부 키가 데이터베이스에 기록되었는지 여부를 고려합니다.버그 수정 릴리스에서는 버그를 수정하고 신속하게 고객에게 수정 내용을 전달할 수 있습니다.그러나 수십 개의 데이터베이스에서 손상된 데이터를 어떻게 수정해야 할까요?외부 키의 무결성에 대한 가정이 더 이상 유지되지 않기 때문에 올바른 코드가 갑자기 끊어질 수 있습니다.

웹 응용 프로그램에서는 일반적으로 데이터베이스와 통신하는 프로그램이 1개뿐이므로 버그가 데이터를 손상시킬 수 있는 곳은 1개뿐입니다.엔터프라이즈애플리케이션에서는, 복수의 독립된 애플리케이션이 같은 데이타베이스에 통신하는 경우가 있습니다(데이터베이스 셸을 직접 사용하는 사람은 말할 것도 없습니다).모든 애플리케이션이 항상, 그리고 영원히 버그 없이 동일한 가정을 따르고 있는지 확인할 수 있는 방법은 없습니다.

제약조건이 데이터베이스에 인코딩되어 있는 경우 버그로 인해 발생할 수 있는 최악의 상황은 사용자에게 일부 SQL 제약조건이 충족되지 않는다는 추악한 오류 메시지가 표시되는 것입니다.이는 손상된 데이터를 기업 데이터베이스에 저장하여 모든 애플리케이션을 중단하거나 잘못된 출력으로 이어질 수 있습니다.

외부 키 제약 조건도 기본적으로 인덱싱되므로 성능이 향상됩니다.외래 키 제약 조건을 사용하지 않을 이유가 생각나지 않습니다.

외국 열쇠가 없으면 장점이 있나요?FK는 데이터베이스 상태가 좋지 않으면 셋업하기 어렵지 않습니다.그럼 왜 그들을 피하는 정책을 가지고 있는 거죠?열이 다른 열을 참조하는 명명 규칙을 갖는 것과 데이터베이스가 실제로 관계를 확인하는 것은 별개의 일입니다.

FK는 매우 중요하며 당신이 eBay가 아닌 한 당신의 스키마 안에 항상 존재해야 합니다.

저는 어떤 시점에서는 어떤 것이 유효한 관계를 보장하는 데 책임이 있다고 생각합니다.

예를 들어 Ruby on Rails는 외부 키를 사용하지 않지만 모든 관계를 검증합니다.Ruby on Rails 어플리케이션에서만 데이터베이스에 액세스 할 수 있습니다.

그러나 데이터베이스에 쓰는 다른 클라이언트가 있는 경우 외부 키가 없으면 자체 검증을 구현해야 합니다.그러면 프로그래머라면 누구나 알 수 있는 가장 다른 두 개의 검증 코드 복사본이 생성됩니다.

이 시점에서는 외부 키를 사용하여 책임을 한 포인트로 다시 이동할 수 있으므로 외부 키가 정말 필요합니다.

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

지금은 모든 것이 괜찮을지 모르지만, 당신의 프로그래머가 떠나고 다른 누군가가 그 자리를 넘겨받을 때 무슨 일이 일어날지 생각해 보세요.

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

제가 알기로는 외부 키는 프로그래머가 데이터를 올바르게 조작할 수 있도록 도와주는 데 사용됩니다.

FK를 사용하면 DBA는 프로그래머가 실패했을 때 사용자의 실수로부터 데이터 무결성을 보호할 수 있으며 때로는 프로그래머의 실수로부터 보호할 수도 있습니다.

프로그래머가 이미 올바른 방법으로 이 작업을 수행하고 있다고 가정하면, 외래 키의 개념이 정말 필요한 것일까요?

프로그래머는 필멸적이고 틀리기 쉽다.FK는 선언적이어서 망치기 어렵다.

다른 외부 키 용도가 있나요?내가 뭘 빠트렸나요?

이것이 그들이 만들어진 이유는 아니지만, FK는 다이어그램 작성 도구와 구축자에게 강력한 신뢰할 수 있는 힌트를 제공합니다.이는 최종 사용자에게 전달되며, 최종 사용자는 강력하고 신뢰할 수 있는 힌트를 절실히 필요로 합니다.

안전벨트가 꼭 필요하지는 않은 것처럼 꼭 필요한 것은 아니다.하지만 데이터베이스를 엉망으로 만드는 바보 같은 짓으로부터 당신을 구할 수 있어요

애플리케이션을 망가뜨린 삭제를 재구성하는 것보다 FK 제약 에러를 디버깅하는 것이 훨씬 좋습니다.

응용프로그램이 데이터베이스에서 데이터를 조작할 수 있는 유일한 방법은 아니기 때문에 이러한 기능이 중요합니다.응용 프로그램은 원하는 대로 참조 무결성을 처리할 수 있지만 데이터베이스 수준에서 적절한 권한을 가진 하나의 bozo를 사용하여 insert, delete 또는 update 명령을 실행하면 모든 응용 프로그램 참조 무결성의 적용이 무시됩니다.데이터베이스 레벨에 FK 제약조건을 넣는다는 것은 명령어를 발행하기 전에 FK 제약조건을 무효로 하는 경우를 제외하고 FK 제약조건으로 인해 잘못된 삽입/갱신/삭제 문이 참조 무결성 위반으로 실패한다는 것을 의미합니다.

비용/편익 측면에서 생각합니다.MySQL에서 제약조건을 추가하는 것은 DDL의 한 줄 추가입니다.그것은 단지 몇 개의 키워드와 몇 초의 생각일 뿐이다.내 생각에는 그게 유일한 '비용'이야

툴은 외부 키를 좋아합니다.외부 키는 비즈니스 로직이나 기능에 영향을 주지 않고 눈에 띄지 않는 불량 데이터(고립된 행)를 방지하고 축적합니다.또한 스키마에 익숙하지 않은 개발자가 관계를 놓치고 있다는 사실을 깨닫지 못한 채 전체 작업 청크를 구현하는 것을 방지합니다.현재 어플리케이션의 범위 내에서는 모든 것이 훌륭할 수 있지만, 만약 당신이 무언가를 놓쳤거나 예기치 않은 것이 추가되었다면(상상적인 보고서 작성), 당신은 데이터베이스 강제 체크 없이 스키마 시작 이후 축적되어 온 불량 데이터를 수동으로 정리해야 할 상황에 처할 수 있습니다.

당신이 무언가를 조합할 때 이미 머릿속에 있는 것을 성문화하는 데 걸리는 약간의 시간이 당신이나 다른 누군가를 몇 달 혹은 몇 년 후에 슬픔의 시간을 구할 수 있을 것이다.

질문:

다른 외부 키 용도가 있나요?내가 뭘 빠트렸나요?

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

엔트로피 감소데이터베이스에서 혼돈 시나리오가 발생할 가능성을 줄입니다.모든 가능성을 고려 중이라 어려움을 겪고 있기 때문에 시스템 유지보수에 있어서 엔트로피 감소가 관건이라고 생각합니다.

예를 들어, 각 주문에는 고객이 있어, 그 전제 조건은 무엇인가에 의해 실시되어야 합니다.데이터베이스에서 "something"은 외부 키입니다.

나는 이것이 개발 속도에서 트레이드오프할 가치가 있다고 생각한다.물론, 전원을 끄면 더 빨리 코드를 입력할 수 있고, 그래서 사용하지 않는 사람도 있을 것입니다.개인적으로 나는 NHibernate와 내가 어떤 수술을 할 때 화를 내는 몇 개의 외국 키 제약으로 몇 시간을 죽였습니다.하지만 문제가 무엇인지 알고 있기 때문에 문제가 되지 않습니다.저는 일반 도구를 사용하고 있으며, 이 문제를 해결하는 데 도움이 되는 리소스도 있고, 도움을 받을 수 있는 사람도 있을 수 있습니다.

다른 방법으로는 외부 키가 설정되지 않아 데이터가 일관되지 않는 시스템에 버그가 침투할 수 있습니다(그리고 충분한 시간이 지나면 버그가 침투할 수 있습니다).그 후, 이상한 버그 리포트를 수신해, 조사해 「OH」라고 합니다.데이터베이스가 망가졌어요.고치는데 얼마나 걸릴까요?

외부 키는 다음과 같은 제약으로 볼 수 있습니다.

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

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

단, 몇 가지 이유로 가까운 장래에 훨씬 더 많이 사용할 수 있게 될 것입니다.두 가지 이유 모두 비슷합니다.

1. 도표 작성올바르게 사용되는 외부 키 관계가 있으면 데이터베이스 다이어그램을 만드는 것이 훨씬 쉽습니다.

2. 도구 지원적절한 외부 키 관계가 있는 경우 LINQ에서 SQL로 사용할 수 있는 Visual Studio 2008을 사용하여 데이터 모델을 구축하는 것이 훨씬 쉽습니다.

즉, 수동 SQL 작업(쿼리 구성, 쿼리 실행, blahblah)이 많은 경우 외부 키가 반드시 필요한 것은 아니라는 것을 알게 되었습니다.하지만 툴을 사용하기 시작하면 훨씬 더 유용하게 사용할 수 있습니다.

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

코드에서는 일반적으로 어딘가에 예외가 발생하지만 SQL에서는 일반적으로 "잘못된" 답변만 얻을 수 있습니다.

이론적으로 SQL Server는 쿼리 계획의 일부로 제약조건을 사용할 수 있지만 파티션 분할에 대한 제약조건을 체크하는 것 외에는 실제로 이를 목격한 적이 없다고 말할 수 없습니다.

내가 작업한 프로젝트(비즈니스 어플리케이션 및 소셜 네트워킹 웹사이트)에서 외부 키가 명시적(FORE KEY REFERENCES 테이블(칼럼))으로 선언된 적은 없었다.

하지만 항상 외래열쇠인 컬럼을 명명하는 일종의 규칙이 있었다.

데이터베이스의 정규화와 마찬가지로 무엇을 하고 있는지, 그 결과(주로 퍼포먼스)를 파악해야 합니다.

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

또한 다양한 데이터베이스 엔진에서 다른 방식으로 외부 키를 처리할 수 있으므로 마이그레이션 중에 미묘한 버그가 발생할 수 있습니다.

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

네. ON DELETE [ RESTRICT | CASCADE ]는 개발자가 데이터를 고립시키는 것을 방지하여 데이터를 깨끗하게 유지합니다.저는 최근에 외부 키와 같은 데이터베이스 제약에 초점을 맞추지 않은 Rails 개발자 팀에 합류했습니다.

운 좋게도, 저는 이것들을 발견했습니다.http://www.redhillonrails.org/foreign_key_associations.html -- Ruby on Rails 플러그인의 RedHill은 구성 스타일에 대한 규약을 사용하여 외부 키를 생성합니다.product_id를 사용하여 이행하면 제품 테이블에 ID에 대한 외부 키가 생성됩니다.

트랜잭션 이행 등 RedHill의 기타 뛰어난 플러그인을 확인하십시오.

데이터 액세스 코드(Entity Framework 또는 기타 ORM)를 생성할 계획인 경우 외부 키가 없는 계층형 모델을 생성할 수 없습니다.

언급URL : https://stackoverflow.com/questions/18717/are-foreign-keys-really-necessary-in-a-database-design