MySQL, 옵션 다중 외래 키 재구성 방법

Question

이 예제에서는 여러 소스의 출력을 허용하는 시스템을 빌드하려고하지만이 소스는 아직 빌드되지 않았습니다. 출력 "모듈"은 하나의 구성 요소가 될 것이고, 각 소스는 나중에 빌드되고 확장 될 자체 구성 요소가 될 것입니다.

목표는 쉽게 더 많은 소스가 내장되어 이후로에 확장되는 동안 출력 테이블에서 내 출력 모듈 디스플레이 데이터를 확인하는 것입니다 :

는 여기에 내가 MySQL 워크 벤치에서 설계 예입니다. 또한 새 소스를 추가 할 때 스키마 업데이트를 최소화하려고합니다. 현재 소스마다 새 테이블을 추가 한 다음 출력 테이블에 외래 키를 추가해야합니다.

더 좋은 방법이 있나요? JOIN 쿼리에 IFNULL이 포함되어있을 수 있으므로이 NULL 가능 외래 키에 대해 어떻게 느끼는지 알 수 없습니다.

생각하십니까?

EDIT 1 : 해설

I 출력 테이블의 데이터를 이용하여 그리드를 표시한다. 출력 테이블은 그리드의 모든 항목에 대한 일반 데이터를 포함하고 기본적으로 output_source_X 테이블의 어 그리 게이터 역할을합니다 :

output(id, when_added, is_approved, when_approved, sort_order, ...) 

output_source_X 테이블은 소스 고유의 추가 데이터가 포함됩니다. 예를 들어, 출력 소스 테이블 중 하나 페이스 북의 게시물입니다 가정 해 봅시다 때문에,이 표는 페이스 북의 API에 고유 한 열이 포함됩니다 : 열이 트위터에 대해 특정 그래서,

output_source_facebook(id, from, message, place, updated_time, ...) 

는 또 다른 트위터 될 수를 :

를

output_source_twitter(id, coordinates, favorited, truncated, text, ...) 

세 번째 출력 원본 테이블은 Instagram 일 수 있으므로 output_source_instagram 테이블에는 Instagram에 특정한 열이 포함됩니다.

출력 항목이 Facebook, Twitter, Instagram 등의 게시물인지에 따라 출력 테이블과 하나의 output_source_X 테이블 중 하나만 외래 키 관계가 있습니다. 따라서 게시물 NULL 가능 외국 키.

output table 
------------ 
foreign key (source_id_facebook) references output_source_facebook(id) 
foreign key (source_id_twitter) references output_source_twitter(id) 
foreign key (source_id_instagram) references output_source_instagram(id) 

나는 나의 관심사는 내가 많이 스키마를 업데이트 할 필요없이뿐만 아니라 다른 소스를 추가 할 있기 때문에 싶습니다으로이 같은 모듈되지 않는 것입니다 같아요. 현재, 외래 키가 null이 아닌 것을 사용하여 output_source_X를 출력 테이블에 조인해야합니다.

Answer 1

이 디자인은 거의 확실하게 몇 가지면에서 나쁩니다.

그 설계가 표현되어 있지만 간단한 일이 뭔가 어떨까 분명하지 않다 :

// source [id] has ... 
source(id,message,...) 
// output [id] is approved when [approved]=1 and ... 
output(id,approved,...) 
// output [output_id] has [source_id] as a source 
output_source(output_id,source_id) 
foreign key (source_id) references source(id) 
foreign key (source_id) references source(id) 

은 어쩌면 당신은 출력 및/또는 소스의 다른 아형이? 소스 및/또는 산출물을 기반으로합니까? 어쩌면 각 소스는 특정 출력을 공급하는 것으로 제한됩니까? "outputs"과 "sources"는 실제적으로 종류의 출력과 소스 인입니다. 이것은 출력이 소스가되는 방식이 아니라 어떤 종류의 출력 - 소스 페어링이 허용되는지에 대한 정보입니까?

응용 프로그램에 대해 작성하려는 기본 문에 대한 열 이름으로 매개 변수화 된 문을 제공해주십시오. 즉, 관심있는 응용 프로그램 관계에 대한 것입니다 (예 : 위의 코드 주석과 같습니다.) (다이어그램 디자인에서는 가능하지만 지나치게 복잡하고 모델링하려는 것을 실제로 반영하지 않을 수 있습니다.)

당신의 편집 제목 : Re :

일대일 외래 키 출력 테이블과의 관계와 출력 항목은 페이스 북, 트위터, 인스 타 그램 경우에 따라 output_source_X 테이블의 ONLY ONE,이있을 것입니다 , etc. ... post, 따라서 NULL 가능 외국 키.

상위 유형의 여러 개의 분리 된 하위 유형이 있습니다.

비어 있지 않은 테이블이 어떤 하위 유형 테이블을 나타내는 열 집합을 갖고있는 하위 유형 테이블을 나타내는 하위 유형 식별자/태그 열이있는 것을 제외하면 상황은 this question과 매우 비슷합니다. Erwin Smout의 & 내 답변을 참조하십시오. 또한 this answer.

은 우리에게 당신이 당신의 응용 프로그램

에 대해 할 기본 문에 열 이름에 의해 파라미터 문을주십시오 당신은 (위와 같이) 간단한 문장을 찾을 수 있습니다. 현재 디자인에 대한 진술을 제공하면 복잡한 것을 알 수 있습니다. 이것도 참조하십시오.

나는 나의 관심사는 내가 많이 에게 스키마를 업데이트 할 필요없이뿐만 아니라 다른 소스를 추가 할 있기 때문에 을 싶습니다으로이 같은 모듈되지 않는 것입니다 같아요.

구조가 적절한 하위 유형 디자인과 비교하여 스키마 변경을 줄이지 않습니다.

어쨌든 DDL이 있습니다. 무결성을 관리하는 DBMS의 손실만으로 DDL을 피하기 위해 부속 유형을 일반화 할 수 있습니다. 은 DDL 대 DML 성능 절충점을 토대로 적절하거나 합당합니다. 재검색 (대개 반 패턴) EAV.

(만을 만들고 & 새로운 테이블을 삭제 불가능하고 있음을 표시 한 후 해당 끔찍한 무결성이 & -concurrency-도전 메가 합류 EAV 정보 - 상응하는 디자인은 테이블과-메타 데이터 인코딩 된 테이블 가능한 한 EAV 사용을 고려해야합니다.)