관계를 처리하는 MVC 프레임 워크로 작업 할 때 외래 키를 정의 할 때의 이점은 무엇입니까?외래 키를 정의 할 때의 이점은 무엇입니까
관계가있는 모델 정의를 허용하는 프레임 워크가있는 관계형 데이터베이스를 사용하고 있습니다. 외래 키가 모델을 통해 정의되기 때문에 외래 키가 중복되는 것처럼 보입니다. 개발시 응용 프로그램의 데이터베이스를 관리 할 때 외래 키를 사용하는 테이블을 편집/삭제하는 것은 번거롭습니다.
내가 사용하고있는 외래 키를 사용하는 데 유리한 점이 있습니까?
제약 조건이있는 외래 키 (일부 DB 엔진)는 낮은 수준 (데이터베이스 수준)에서 데이터 무결성을 제공합니다. 이는 관계를 충족시키지 않는 레코드를 실제로 만들 수 없다는 것을 의미합니다. 더 안전한 방법 일뿐입니다.
또 다른 이점은 계단식 DELETE입니다. 예를 들어'User' 테이블과'Class' 테이블이 있다고 가정 해 봅시다. 클래스의 모든 사용자 데이터를 다시 쓰는 대신 사용자의 ID 만 참조하면됩니다. 그러나 해당 사용자가 삭제되면 어떻게 될까요? 계단식 삭제 기능이 켜져 있지 않으면 클래스 테이블의 행이 존재하지 않는 사용자를 가리 킵니다. 해당 사용자 ID가 완전히 다른 사용자로 대체되면 어떻게됩니까? 그 때 물건이 정말로 나 빠지게됩니다. 계단식 삭제는 해당 사용자와 관련된 모든 레코드를 삭제합니다. 이것은 중요하지 않겠지 만,'User'가 많은 테이블에 연결되어 있다면, 이것은 많은 도움이됩니다. –
비용은 있습니까? – Ahmad
데이터베이스 수준에서 적용되는 데이터 무결성을 제공합니다. 이렇게하면 잘못된 데이터가 발생할 수있는 응용 프로그램 논리의 오류를 방지 할 수 있습니다.
SQL에서 직접 응용 프로그램 논리를 우회하는 데이터 조작이 수행되면 이러한 제한 조건을 벗어나는 잘못된 데이터도 보호합니다.
추가 이점은 도구를 사용하여 스키마 자체에서 유추 된 관계로 데이터베이스 다이어그램을 자동으로 생성 할 수 있다는 점입니다. 이제 이론적으로 모든 다이어그램 작성은 데이터베이스가 작성되기 전에 수행되어야하지만 데이터베이스가 초기 구체화 이상으로 진화함에 따라 이러한 다이어그램은 종종 최신 상태로 유지되지 않으며 기존 데이터베이스에서 다이어그램을 생성하는 기능은 검토, 프로젝트에 참여하는 신규 개발자에게 구조를 설명하는 역할을합니다.
데이터베이스 구조가 여전히 유동적이지만 FK를 사용하지 않도록 설정하는 것이 유용 할 수 있지만 스키마가 안정화 될 때 좋은 보호 장치입니다.
외부 키는 일치하는 레코드가 외부 테이블에 있음을 보장합니다. 테이블에 Authors이라는 FK 제약 조건이있는 Books이라는 테이블을 상상해보십시오. 모든 서적은 Author으로 보장됩니다. 당신의 데이터 세트에서 책을 누락 결과, 전체 Book 행을 야기 누락 Author 행이 삭제 될 수있는 FK 제약없이
SELECT B.Title, A.Name FROM Books B
INNER JOIN Authors A ON B.AuthorId = A.AuthorId;
:
지금, 당신은 같은 쿼리를 할 수 있습니다.
또한 FK 제약 조건을 사용하면 하나 이상의 책에서 참조한 작성자를 삭제하려고하면 데이터베이스가 손상되는 대신 오류가 발생합니다.
주요 이점은 데이터 무결성 및 계단식 삭제입니다. 또한 정의되고 해당 필드가 올바르게 색인화 될 때 성능 향상을 얻을 수 있습니다. 예를 들어 연락처에 속하지 않은 전화 번호를 만들 수 없거나 연락처를 삭제할 때 모든 전화 번호를 자동으로 삭제하도록 설정할 수 있습니다. 예, UI 또는 중간 계층에서 이러한 연결을 만들 수 있지만 사용자가 UI 대신 SQL을 사용하여 서버에 대해 직접 업데이트를 실행하면 고아가됩니다. "번거 로움"부분은 대량 변경을하기 전에 이러한 연결을 고려하도록합니다. FK는 여러 번 내 베이컨을 구했습니다.
개발/테스트 데이터를 조작 할 때 고통이 될 수 있지만 제작 과정에서 많은 번거 로움을 덜어 줬습니다.
데이터 무결성을 유지하는 방법으로 특히 고아 레코드에 대한 보호책으로 생각하십시오. 당신이 Person 많은 PhoneNumber 기록을 관련 데이터베이스를 가지고있는 경우 Person 레코드가 어떤 이유에서 삭제 될 때
예를 들어, 어떤 일이 PhoneNumber 기록은 어떻게됩니까? 그들은 여전히 데이터베이스에 존재하지만 관련된 Person의 ID는 관련 Person 테이블에 더 이상 존재하지 않으며 고아 레코드가 있습니다.
예, Person이 제거 될 때마다 PhoneNumber을 삭제하는 트리거를 작성할 수 있지만 우연히 Person을 삭제하고 롤백해야하는 경우 지저분해질 수 있습니다.
예, 수동으로 PhoneNumber 개의 레코드를 제거하는 것을 기억할 수도 있지만, 9 개월 동안 다른 개발자 나 방법을 작성하면 어떨까요?
PhoneNumber이 기존 Person과 관련이 있음을 보장하는 외래 키를 생성하면이 관계를 파괴하지 않도록하고 의도 한 데이터 구조에 대해 '단서'도 추가 할 수 있습니다.
외래 키 관계는 데이터 계층에서 데이터 무결성을 유지함으로써 시스템에 들어오는 불량 데이터를 줄입니다. 아니 정말. 예를 들어 성별 테이블과 FK 관계가있는 사람 테이블이있는 경우 개발자는 성별이 'whocares'인 사람에게 레코드를 삽입 할 수 있습니다. 자, 당신은 이것에 신경 쓰지 않을 수 있습니다. 그러나 논리가 유효한 항목을 만들고 남성/여성만을 기대한다면, 그러면 ... 당신은 문제가 생길 것입니다. ERD를 얻기 위해 DB를 리버스 엔지니어링하려는 경우에도 문제가 발생할 수 있습니다. 그리고 스 캐 폴딩 및 기타 기술은이 수준의 디자인에서 중계합니다 ... – xQbert
매우 관련이 있습니다 : [왜 외래 키가 실제로 연습보다 이론에 사용됩니까?] (http://stackoverflow.com/questions/1876013/why-are-foreign -keys-more-in-in-practice) –
우리는 일하던 곳에서 비슷한 시나리오를 보였습니다. 하나의 앱에는 외래 키가 없었습니다. 왜냐하면 ORM이 이러한 모든 문제를 처리했기 때문입니다. 중요한 고객은 중요한 데이터 손실을 발견했으며 결국 ORM의 버그로 추적되었습니다. ORM 개발자를 비난하는 것은 도움이되지 않는다. 외국 열쇠는 곧 추가되었습니다! – onedaywhen