동료에게 조인 테이블의 이점을 설명하려고하고 있습니다. 아래는 설명입니다. 나 맞아?조인 테이블의 장점은 무엇입니까?
현재 그는 두 개의 테이블이있는 그림과 태그 사이의 관계가 있습니다. 그림 테이블과 태그 테이블. 그림 테이블에는 tag_id
이 있습니다. 이는 태그 테이블의 항목에 대한 FK입니다. 여기 내 반응은 다음과 같습니다.
먼저 pics
및 tags
표를보십시오. 그래서 현재의 아키텍처에서 두 개의 사진 (& b)을 상상할 수 있습니다. 해시 태그 #wtf를 사용하여 사진에 & b 개의 태그를 지정합니다. 우리는 이제 밖으로 두 개의 항목을 가지고 tags
테이블 :
pic_id title
------ -----
a wtf
b wtf
당신은 문제가 보이나요? 1000 개의 다른 사진에 1000wtf의 태그가 있다고 상상해보십시오. 이 아키텍처를 사용하여 모든 반복 된 데이터 (낭비 된 공간)가있는 비 대한 태그 테이블을 갖게되었습니다. 이 문제는 다 대다 관계가있을 때 발생합니다. 이 경우 많은 사진들이 많은 태그를 가질 수 있으며 많은 태그는 많은 사진을 가질 수 있습니다. 어떻게 해결할 수 있을까요? 대답은 조인 테이블입니다. 그래서 우리는 새로운 테이블을 만듭니다. 전화 번호는 pic_tag
입니다. 이 테이블의 열은 pic_id
& tag_id
입니다. 이제 새로운 테이블과 같습니다
pic_tag
pic_id tag_id
------ ------
a 1
b 1
태그
id name
-- ----
1 wtf
을 그림
id name
-- ----
a pic1
b pic2
그래서 우리에게 몇 가지가 않습니다. 먼저 공간을 절약합니다. 'wtf'라는 문자열을 한 번만 저장합니다. 둘째, 태그 'wtf'로 모든 사진을 찾으려면 먼저 태그 테이블로 이동하여 'wtf'의 ID를 찾은 다음 pic_tag 테이블로 이동하여이 ID를 검색하면 훨씬 효율적입니다. '주어진 텍스트에 대한 테이블. 다른 말로하면 int를 검색하는 것이 텍스트를 검색하는 것보다 훨씬 빠릅니다.
데이터 중복이 없으며 데이터 무결성이 뛰어나고 성능이 저하됩니다. –
@ AD.Net : "느린 성능"--- 이것은 잘못된 것입니다. 데이터를 정규화하면 * 추상 * 성능 * 메트릭이 없기 때문에 * 더 느려지는 것을 알 수는 없지만 주어진 구조에 대해 다른 성능 측면의 수는 * 더 우수 할 수 있습니다. – zerkms