나는이 질문에 상당히 부끄럽지만 최근에는 서로 관련이있는 세 가지 유형의 은행 엔티티에 대해 하나의 테이블을 작성해야하는 상황이있었습니다. 설명하겠습니다.데이터베이스 테이블의 순환 참조
통치 은행 또는 시골 지부를 운영하는 일반 은행 또는이 계좌에 해당하지 않지만 거래가있는 농촌 지사가있는 지사 표를 상상해보십시오. 농촌 지사.
이전에는 FK 제약 조건 (예 : 통치 은행, 농촌 지사, 농촌 지사 및 소매 은행 지점을 운영하는 은행)에 대해 4 가지 테이블을 사용하기로 결정했습니다. 그러나 TRANSACTION 테이블을 만들기 위해 계속 진행했을 때 거래가 이러한 엔티티 중 하나 (예 : 시골 지점 & 소매 지점, 시골 지점 자체 사이 등) 사이에서 발생할 수 있으므로 당황했습니다. 이것은 Banking Entity의 "Source"& "Destination"ID의 레코드를 보관할뿐만 아니라 쿼리를 위해 JOIN 할 테이블을 애플리케이션 로직이 결정할 수 있도록 일부 데이터를 유지해야한다는 것을 의미했습니다.
또한 USER 테이블이 있으며 사용자가 이러한 엔티티 중 하나에 속할 수 있습니다. 여기에는 4 개의 은행 엔티티 테이블도 문제가 있습니다. 사용자가 시골 지사 또는 소매점에 속하는지 어떻게 알 수 있습니까? Branch 또는 the Governing bank?
따라서 하나의 BANK 테이블을 만들었습니다. (본질적으로 그들은 서로 거래 할 수있는 유사한 엔티티이기 때문에) ID의 값을 보유 할 수있는 PARENT 열을 테이블에 추가했습니다. 부모 기관의 관계 herwise는 FK를 사용하여 달성). 따라서 시골 지부는 모회사 칼럼에 영업 은행이라는 ID를 갖게됩니다. 소매 지점에는 부모가 없으므로 값은 NULL입니다.
지금까지 살펴본 문제는 BANK 테이블에 순환 참조 인 PK/FK 관계가 있다는 것입니다.
내 질문은 : 얼마나 나쁘니? 그리고 탈출구가 될 수있는 것은 무엇입니까?