다른 중간 중간 테이블의 올바른 이름

Question

Event, Message, Flow 및 Document 4 엔티티가 있습니다.

Event 테이블에는 제한된 (시드 된) 레코드 수가 저장됩니다. Message에는 많은 이벤트가 있으며 각 이벤트는 많은 메시지와 관련 될 수 있습니다. 중간 표에는 event_message이라는 이름이 지정되었습니다.

중간 테이블의 규칙은 다음과 같습니다. {tablename}_{tablename}.

Flow 테이블에는 제한된 (시드 된) 레코드 수가 저장됩니다. Message에는 많은 플로우가 있으며 각 플로우는 많은 메시지와 관련 될 수 있습니다. 중간 표에는 flow_message이라는 이름이 지정되었습니다.

Flow과 Message (각 레코드는 flow_message) 사이의 관계마다 문서가 만들어집니다.

문제

는 여기서 시작 : 메시지에

각 이벤트는 흐름에 의해 서로 다른 문서가 있습니다. 즉, 중간 테이블 flow_message의 각 새 레코드에 대해 event_message 중간의 각 레코드에 관련된 새 문서가 있습니다.

이 문제를 해결하기 위해 이라는 중간 테이블을 event_message과 flow_message 사이에 만들었습니다.

(일부 기존의 방식)이 맞습니까? 이 모델링이 올바른가요?

중급 테이블 미분을 중간 테이블 2 개로 나누어 모델링하는 방법은 무엇입니까?

Answer 1

나는 또한 대회가 있었으면 좋겠습니다. 내가 공식 대회를 모르기 때문에 나는 내 것을 발명했다. 중요한 것은 당신이 선택한 대회를 존중하는 것입니다.

그래서 event_message_flow_message을 rel_eventmessage_flowmessage으로 변경합니다. 그러나 나에게있어 당신의 국제 대회는 꽤 좋다.

Answer 2

귀하의 모델이 조금 이상해 보임에 따라 권장하기가 어렵습니다. DOCUMENT과 FLOW_MESSAGE 및 DOCUMENT 및 EVENT_MESSAGE_FLOW_MESSAGE 사이에 1 : 1 관계가 있습니다. EVENT_MESSAGE_FLOW_MESSAGE에 대한 다기간 관계로 내 마음 속에서 이것을 화해시키기는 어렵습니다. DOCUMENT과의 관계가 실제로 1 : 1 (필수) 인 경우 별도의 테이블에 문서를 보관해야하는 이유는 무엇입니까?

테이블 이름 지정에 관한 질문에 답하려면 : 교차 테이블 이름 지정을위한 {table} _ {table} 규칙은 모범 사례가 아니라 더 나은 이름을 생각할 수없는 경우를 대비 한 대안이라고 주장합니다 .

테이블에있는 데이터로 기록/설명되는 사업체 이름을 반영하는 것이 가장 좋습니다. 특히 교차로 테이블의 경우이 작업을 수행 할 수있는 것은 아닙니다. 교차 테이블은 다 대다 관계를 나타내고 관계는 종종 명사로 설명하기 어렵습니다.

귀하의 경우 귀하의 국제 대회가 실제로 이해하기가 쉽지 않다고 생각합니다. 나는 아마도 MESSAGE_DOCUMENT 또는 심지어 단지 DOCUMENT과 같은 것으로 단순화하려고 노력할 것입니다. 어쨌든 1 : 1과 관련이 있기 때문입니다.