스키마 : 양방향 관계? 어떤 테이블/엔티티가 '환경 설정'을 소유해야합니까?

Question

이 질문을하는 방법을 모르겠으므로 예제를 통해 내가 할 수있는 한 분명 할 것입니다.

페이스 북과 같은 앱에서 프로필은 여러 개의 ProfilePictures를 가질 수 있습니다. 주어진 시간에 이들 중 하나가 "선택된"ProfilePicture입니다 (ProfilePicture가 업로드되었다고 가정).

본능적으로, 나는이 같은 모델 것 :

Table: Profile 
-------------- 
ProfileID 
SelectedProfilePictureId //fk to ProfilePicture 
Name, Age, Etc 

Table: ProfilePicture 
--------------------- 
ProfilePictureId 
ProfileId //fk to Profile, indicating which Profile this picture belongs to 
Url, DateTaken, Etc 

을이 시점에서, 이러한 테이블은 서로 지적하고 그냥 나에게 "잘못된"것으로 보인다. 그것은 쉽게 SelectedProfilePictures없이 프로필을 쿼리하거나 프로필의 SelectedPicture를 얻을 수 있지만 삽입과 업데이 트가 좀 어색합니다.

이 나쁜 형태입니까? 프로필 테이블이 ProfilePicture 테이블과 완전히 독립적이어야합니까? 데이터베이스 설계 이론에 따라 이것을 모델링하는 "올바른"방법이 있습니까, 아니면 프로그래머의 강점입니까?

Answer 1

정확합니다. 순환 참조라고하며 실제로 데이터베이스로 만들 수 없습니다.

하나의 간단한 해결책은 그림의 하위 표에 "기본 설정"플래그입니다. 그러나 당신은 여기에 문제가 있습니다 : 주어진 사람을위한 한 줄만 선호 될 수 있습니다. 따라서 누구라도 새로운 사람을 선호하는 사람으로 표시하면 다른 사람은 모두 지워야합니다.

보다 안전한 해결책은 외부 키가있는 "preferredPictures"테이블을 Profiles 및 ProfilePictures에 추가하는 것입니다. profileId에서 고유하게 만들 수 있으므로 하나 이상의 항목을 가질 수 없습니다. 이렇게하면 이전 항목을 삭제 한 후 새 항목을 삽입합니다. 또는 물론 기존의 업데이트 만 수행 할 수 있습니다.

편집 의견 :. 어린이 1 :

1) 프로필 기 때문에 순환 참조는 기술적으로 1 인 것이 정보

Profiles 
    | | 
    | +-----> PreferredPicture 
    | +-----> 
    | | 
    \|/ | 
ProfilePictures 

2) 원하는 화면의 기본 키 profileID가되는 주위에 루프를하지 않고, 모두 하위 테이블 부모 프로필 테이블.

Answer 2

왜 ProfilePicture 테이블에서 ProfileID를 유지해야합니까?

이 필요하면 당신은 당신이 연결을 구축하는 3 표해야 할 수 있습니다

profileID가를 < -> ProfilePictureID

내가 전에 다른 프로젝트의 "순환 참조"의 종류와 작업 한

Answer 3

.

Profile.SelectedProfilePictureId가 Nullable이고 ProfilePicture.ProfileId가 필수이면 괜찮습니다. 오직 두 개의 fk를 필수로 설정해야만 불가능합니다.