포트폴리오의 테이블 디자인을 검토했습니다.
2493 단어 SQL
머리
2장 Naive Trees(소박한 나무) 을 참고로 자신의 포트폴리오를 재검토해 보았습니다.
RDB의 데이터 구조
RDB의 데이터 구조에는 크게 4가지가 있습니다.
①인접리스트 모델(나이브 트리)
② 경로 열거 모델
③ 폐쇄 테이블 모델
④ 중첩 집합 모델
소박한 나무란?
소박한 나무는 ①의 인접 목록 모델에 해당합니다.
예
인접 목록 모델은 가장 간단한 구조로 다음과 같은 테이블입니다.
특징은 각 요소가 자신의 부모만을 알고 있다는 것입니다.
id
이름
parent_id
1
지명
NULL
2
일본
1
3
미국
1
4
도쿄
2
5
오사카
2
6
시부야
4
7
스이타
5
8
시나가와
4
9
뉴욕
3
10
나이아가라
9
11
로스앤젤레스
3
장점, 단점
RDB의 데이터 구조에는 크게 4가지가 있습니다.
①인접리스트 모델(나이브 트리)
② 경로 열거 모델
③ 폐쇄 테이블 모델
④ 중첩 집합 모델
소박한 나무란?
소박한 나무는 ①의 인접 목록 모델에 해당합니다.
예
인접 목록 모델은 가장 간단한 구조로 다음과 같은 테이블입니다.
특징은 각 요소가 자신의 부모만을 알고 있다는 것입니다.
id
이름
parent_id
1
지명
NULL
2
일본
1
3
미국
1
4
도쿄
2
5
오사카
2
6
시부야
4
7
스이타
5
8
시나가와
4
9
뉴욕
3
10
나이아가라
9
11
로스앤젤레스
3
장점, 단점
장점
단점
(일본에 관한 자손 트리의 수를 얻기 어려워진다)
현재의 구조
코멘트를 thread 형식으로 표시하는 기능으로,
코멘트, 코멘트에 대한 회신은 모두 Comments 테이블에 저장됩니다.
comment_id
콘텐츠
reply_comment
1
아침밥을 먹었다
NULL
2
일찍 일어났습니다.
NULL
3
무엇을 먹었습니까?
1
4
오늘은 외출
NULL
5
나도 먹었다!
1
(reply_comment는 어떤 댓글에 대한 회신을 나타냅니다)
이번 패턴에서는
계층은 2 계층으로 고정
의 구조이므로, 단점의 부분을 의식할 필요는 없고 인접 리스트 모델에서도 문제 없을까라고 생각합니다.
개선한다면
향후, 개선으로서 thread내에서 한층 더 어느 코멘트에 대한 코멘트를 세세하게 분류하고 싶은 경우는, 인접 리스트 모델에서는 불충분하다고 생각됩니다.
그 때는, 폐포 테이블 모델을 채용해 테이블을 2개로 나눌 필요가 나옵니다.
참고문헌
The Cusp Of Helix
Rails에서 트리 구조(계층 구조)를 가지는 카테고리를 인접 리스트 모델로 구현한다
Reference
이 문제에 관하여(포트폴리오의 테이블 디자인을 검토했습니다.), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/kensuke_kumaki/items/8e75b41357d6031cef6c
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
Reference
이 문제에 관하여(포트폴리오의 테이블 디자인을 검토했습니다.), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://qiita.com/kensuke_kumaki/items/8e75b41357d6031cef6c텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)