데이터베이스 디자인에서 many-to-many 관계

Question

현재 기사 및 태그라는 두 개의 테이블이있는 데이터베이스가 있습니다. 기사가 여러 범주에 속할 수 있도록하기 위해 나는 많은 관계를 가지고 있습니다. 성능 측면에서 그러한 디자인을 갖는 것은 실수입니까? 또는이 두 테이블 간의 관계를 제거하고 세 번째 테이블을 브리지 (articlesTags)로 추가해야합니까?

Answer 1

다 - 대 - 다 관계가있는 것이 본질적으로 잘못되었으므로 그 관계를 촉진하기 위해 Junction Table (이는 articlesTags을 말하는 것 같습니다)을 만들어야합니다.

Answer 2

데이터에 필요한 경우 다 대다 관계를 유지하는 데는 문제가 없지만 세 번째 테이블에서이를 나타낼 수 있습니다.

Answer 3

관계형 모델에는 다 대다 관계가 있습니다. 이것은 단지 마음의 추상화 일뿐입니다. 많은 사용에 아무 문제가 없습니다

fk_article (정수) fk_tag (정수)

CF http://en.wikipedia.org/wiki/Many-to-many_(data_model)

Answer 4

: 당신이 그것을 구현하는 것입니다 때 당신이 가진거야 articles_to_tags 테이블이있을 것 많은 관계. 종종 필요합니다.

네, 세 번째 테이블을 사용하지 않고도 여러 관계를 만들 수는 없습니다.

Answer 5

개념적 데이터베이스 디자인 (N : N 관계)과 물리적 구현의 차이가 있습니다. N : N 관계를 어떻게 모델링하든 관계없이 앞서 언급 한 정션 테이블이 필요합니다.

일반 성명서와 같이 실제 세계에 가깝게 실제 세계 관계를 모델링하는 데는 아무 문제가 없습니다. 선명도는 왕이다.

어떤 시스템에서든 성능 문제에 관한 답변은 대개 "의존적"입니다.

성능 문제가 WRITES와 관련되어 있으면 고도로 NORMALIZED 구조가 가장 좋으며 접합 표가 필요할 것입니다. 결국 적은 데이터를 작성하게되며, 결과적으로 속도가 빨라질 수 있습니다. 삽입물을 만들기 전에 조회를 수행해야한다는 이점이 있습니다. 개별 정규화 된 테이블을 읽는 것은 매우 빠릅니다.

문제가 분석적 READS와 관련되어 있으면 DENORMALISED 구조가 가장 좋습니다. 조인은 테이블이 크고 인덱스가 펼쳐지면 매우 성능 집약적입니다. 당신은 많은 시간을 얻기 위해 많은 공간을 희생 할 것입니다.

일반적으로 해결책을 결정하기 전에 각 상황의 특성을 살펴보고 각 방법의 장단점을 비교하고자합니다. 개인적으로 나는 초기 단계에서 Clarity에 초점을 맞추는 것이 더 좋았고 나중에 문제가 발견되면 성능을 위해 리펙터를 사용하는 것이 더 좋습니다.