복잡한 데이터베이스 관계 (접합 테이블)

Question

내 질문에 관한 비슷한 테이블에 대한 두 접합 테이블을 하나로 결합하는 아이디어입니다. 무슨 뜻인지 읽어보십시오. 또한 이것이 실제로 내가 직면 한 문제이며 따라서이 포럼과 관련이 있음을 주목하십시오. 그것은 당신이 원한다면 "우수 사례"에 대한보다 나은 인구 조사를 얻기 위해 다양한 전문가로부터 좀 더 많은 참여를 이끌어 내기를 희망하는 폭 넓은 결과의 주제 일뿐입니다.

나는 다소 어려운 데이터베이스 디자인 문제가 있습니다. 나는 이것이 많은 사람들이 기여하고 배울 수있는 일종의 위키가되기를 바라고 있습니다. 이 작업을보다 쉽게 ​​수행하기 위해 일련의 그래픽을 만들었으며 문제를 1) 프로세스, 2) 구조로 나눕니다.

프로세스

1. 문서 (공개)에 대한 요청 (DocRequest) 단계 이루어진다.
2. 게시가 아직없는 경우 새 게시가 생성됩니다.
3. 실행중인 로그 (StatusReport)는 요청 수행에 대한 진행 상황을 유지합니다.

참고 : 특정 출판을 위해 많은 DocRequests 및 (업데이트 포함) StatusReports

데이터베이스 구조가있을 수 있습니다

참고 : DocRequest 및 StatusReport 테이블 모두 다양한 분야를 가지고 첨부 그래픽에 표시되지 않은 지원 테이블. 또한 특정 게시는 해당 테이블의 모든 레코드가 속한 마스터 레코드입니다.

--Current Implementation--

참고 :이 디자인의 주요 결함은 새 DocRequest 및 StatusReport 기록을 만들 때마다, 당신은 또한 출판물에 새로운 레코드를 작성해야한다는 것입니다 테이블 (junction 테이블과 같은 역할을 함)을 사용하지만 결과적으로 새로운 공개를 작성합니다. 이것은 바람직한 행동이 아닙니다.

--Typical Implementation-- (이러한 유형의 관계에 대한)

참고 :이 좋아, 아마도 이상적이지만, 독립적으로 연결의 DocRequest 및 StatusReport 테이블 하나에 업데이트를 처리 그들이 속한 출판물에. (이 특별한 경우에 대한) 아니야 자,가요 선호 Implementation--

참고 : 여기 있었다 아이디어는, 하나에 이중 접합 테이블을 결합하는 간단했다. 이 경우 접합 테이블은 DocRequest 또는 StatusReport가 삽입이 발생할 때마다 새 레코드를 가져옵니다. 나는 이것을 방아쇠로 처리 할 것입니다.

토론 지금

토론. 나는 이것이 나쁜 생각이고 이것이 어떤 문제가 발생할 수 있다고 생각한다면 동료 데이터베이스 개발자로부터 알고 싶습니다. 나는 레코드의 순수한 숫자가 두 개의 분리 된 접합 테이블과 동일해야하며 사실 여분의 ID 컬럼을 저장함으로써 약간 더 적은 공간을 사용한다고 생각한다. :)

너희들이 생각하는 것을 나에게 알려줘. 나는이 토론에 많은 사람들이 참여하도록하고 싶다. 건배! :)

Answer 1

나는 당신이 접합점의 관점에서 생각함으로써 자신을 상처주고 있다고 생각합니다. 테이블을 생각해보십시오. StatusReport 이후

• 는 어떻게 든 두에 관한 테이블이 필요 , 문서 요청의 상태와 관련이있다.
• "StatusReport"는 문서 요청 상태에 대한 사실을 저장하는 테이블에 대한 지독한 이름입니다.
• "ID"는 테이블의 모든 열에 대한 지독한 이름입니다.
• 발행물의 ID 번호는 요청의 상태보다 문서 요청과 관련이있는 것으로 보입니다. (당신이 말하기를, "새로운 출판물은 출판물이 이미 존재하지 않는다면 만들어집니다."솔직히 말하면, 그것은 이해가 안가는 것의 거의 끝까지 스케이팅하고 있습니다.) 따라서 발행 번호는 DocRequest 테이블에 거의 확실하게 포함되어 있습니다.

선호하는 구현 다이어그램을 참조하여 TripleJunction 테이블을 삭제하고 StatusReport를이 테이블로 바꿉니다.

-- Predicate: Document request number (doc_request_id) has status (status) 
--   as of date and time (status_as_of). 
create table document_request_status (
    doc_request_id integer not null references DocRequest (id), 
    status_as_of timestamp not null default current_timestamp, 
    status varchar(10) not null, 
    -- other columns go here 
    primary key (doc_request_id, status_as_of) 
);