(적어도 주변)

Question

좋은 오후를 외부 키의 예측할 수없는 번호를 사용 대다 DB 스키마,

내가 가진 건물 대다 나는 문제가 건물에 봉착 관계 스키마 . 주요 문제는 내가 일차 및 외래 키 (일을 단순화하기위한 varchars 또는 enums)로만 작업하고 있고 다 대다 관계의 수는 예측할 수 없으며 언제든지 증가 할 수 있다는 것입니다.

다양한 질문을 둘러 보았으므로이 문제를 직접 해결 한 것을 찾을 수 없었습니다.

문제를 반으로 나누었으므로 이제 일대 다 스키마가 두 개 있습니다. 하나는 해결되었지만 다른 하나는 저에게 적합합니다.

테이블 FOO는 간단한 기본 키가있는 표준 지루한 테이블이라고 가정합시다. 그것은 일대 다 (one-to-many) 관계에있는 것입니다.

표 BAR은 FOO의 여러 키와 관련 될 수 있습니다. 관련 키의 수는 미리 알 수 없습니다.

예

:

1. 쿼리 FOO에서이 식별자 3, 4를 반환 ID의 숫자가있을 수 있지만 5
2. BAR (3 관련 고유 키, 4, 5 필요 조인 보통 테이블이 작동하지 않습니다

) 반환 : FOO 3 고유 키를 반환

Table FOO_BAR 
primary_key | foo_id | bar_id | 

이후 및 여기 bar_id는 foo_id와 일대일 관계가 있습니다.

2 개의 조인 테이블을 가지고 있어도 foo_ids 3, 4, 5를 하나의 bar_id에 매핑 할 수 없으므로 작동하지 않는 것 같습니다.

Table FOO_TO_BAR 
primary_key | foo_id | bar_to_foo_id | 

Table BAR_TO_FOO 
primary_key | foo_to_bar_id | bar_id | 

내가 뭘 잘못하고 있니? 나는 그들이하는 것보다 더 복잡한 것을 만들고 있습니까? 어떻게 문제에 접근해야합니까? 도움을 많이 주셔서 감사합니다.

Answer 1

FOO-BAR은 괜찮아 보입니다. 왜 그렇게 생각하지 않아?

Say FOO = 1,2,3 
Say BAR = A,B,C 

Then an everything to everything relation will look like: 
FOOBAR = 1, A; 1, B; 1, C; 2, A; 2, B; 2, C; 3, A; 3, B; 3, C 

당신은 기본 키 foo_id, bar_id, 당신이 정말로 일을하지 않으려면 별도의 키에 대한 필요성을 만들 수 있습니다, 그 중복 관계를 방지 할 수 있습니다.