내가 아는 한, 외래 키 (FK)는 프로그래머가 올바른 방식으로 데이터를 조작하도록 돕는 데 사용됩니다. 프로그래머가 실제로이 작업을 이미 올바른 방식으로 수행하고 있다고 가정하면 외래 키 개념이 정말로 필요합니까?
외래 키에 대한 다른 용도가 있습니까? 여기에 뭔가 빠졌나요?
답변
외래 키는 데이터 수준에서 참조 무결성을 적용하는 데 도움이됩니다. 또한 일반적으로 기본적으로 색인이 생성되기 때문에 성능도 향상됩니다.
답변
외래 키는 프로그래머가 ON DELETE CASCADE. 즉, 사용자를 포함하는 하나의 테이블과 주문 등을 포함하는 다른 테이블이있는 경우 사용자를 삭제하면 해당 사용자를 가리키는 모든 주문이 자동으로 삭제 될 수 있습니다.
답변
외래 키없이 데이터베이스를 디자인하는 것은 상상할 수 없습니다. 그것들이 없으면 결국 실수를하고 데이터의 무결성을 손상시킬 수밖에 없습니다.
엄격히 말하면 필수 는 아니지만 이점은 엄청납니다.
나는 FogBugz 가 데이터베이스에 외래 키 제약 조건을 가지고 있지 않다고 확신 합니다. 나는 Fog Creek Software 팀이 불일치가 발생하지 않도록 코드를 구조화 하는 방법을 듣고 싶습니다 .
답변
FK 제약이없는 데이터베이스 스키마는 안전 벨트없이 운전하는 것과 같습니다.
언젠가는 후회하게 될 것입니다. 설계 기본 사항과 데이터 무결성에 약간의 추가 시간을 소비하지 않는 것은 나중에 골치 아픈 일을 확실하게하는 확실한 방법입니다.
응용 프로그램에서 그렇게 엉성한 코드를 수락 하시겠습니까? 멤버 개체에 직접 액세스하고 데이터 구조를 직접 수정했습니다.
왜 이것이 현대 언어에서 어렵고 용납 할 수 없다고 생각 합니까?
답변
예.
- 그들은 당신을 정직하게 유지합니다
- 새로운 개발자를 정직하게 유지합니다.
- 넌 할 수있어
ON DELETE CASCADE - 테이블 간의 링크를 자체 설명하는 멋진 다이어그램을 생성하는 데 도움이됩니다.
답변
프로그래머가 실제로이 작업을 이미 올바른 방식으로 수행하고 있다고 가정합니다.
그런 가정을하는 것은 매우 나쁜 생각 인 것 같습니다. 일반적으로 소프트웨어는 엄청나게 버그가 많습니다.
그리고 그것이 정말로 요점입니다. 개발자는 일을 제대로 할 수 없으므로 데이터베이스가 잘못된 데이터로 채워지지 않도록하는 것은 좋은 일입니다.
이상적인 환경에서는 자연 조인이 열 이름과 일치하는 대신 관계 (예 : FK 제약 조건)를 사용합니다. 이것은 FK를 더욱 유용하게 만들 것입니다.
답변
개인적으로 저는 외래 키가 테이블 간의 관계를 공식화하기 때문에 선호합니다. 귀하의 질문은 프로그래머가 참조 무결성을 위반하는 데이터를 도입하지 않는다고 가정한다는 것을 알고 있지만 최선의 의도에도 불구하고 데이터 참조 무결성이 위반되는 사례를 너무 많이 보았습니다!
사전 외래 키 제약 (선언적 참조 무결성 또는 DRI라고도 함)은 트리거를 사용하여 이러한 관계를 구현하는 데 많은 시간을 소비했습니다. 선언적 제약으로 관계를 공식화 할 수 있다는 사실은 매우 강력합니다.
@John-다른 데이터베이스는 외래 키에 대한 인덱스를 자동으로 만들 수 있지만 SQL Server는 그렇지 않습니다. SQL Server에서 외래 키 관계는 제약 일뿐입니다. 외래 키에 대한 인덱스를 별도로 정의해야합니다 (유용 할 수 있음).
편집 : IMO, ON DELETE 또는 ON UPDATE CASCADE를 지원하는 외래 키 사용이 반드시 좋은 것은 아닙니다. 실제로는 데이터의 관계를 기반으로 삭제시 캐스케이드를 신중하게 고려해야한다는 사실을 발견했습니다. 예를 들어 이것이 괜찮을 수있는 자연스러운 부모-자식이 있거나 관련 테이블이 조회 값 집합 인 경우입니다. 계단식 업데이트를 사용하면 한 테이블의 기본 키를 수정할 수 있음을 의미합니다. 이 경우 테이블의 기본 키가 변경되어서는 안된다는 일반적인 철학적 불일치가 있습니다. 키는 본질적으로 일정해야합니다.
