리자

게시판 테이블 구조로 적당한 것은?

 
배포용의 게시판을 말씀 드리는 것입니다.
 
1. 모든 게시판의 게시글과 코멘트를 하나의 테이블로 가져감 (테이블수는 1개)
 
2. 지금의 그누보드와 같이 게시판 별로 게시글과 코멘트를 하나의 테이블로 가져감 (테이블수 = 게시판수)
 
3. 모든 게시판의 게시글 테이블 하나, 모든 게시판의 코멘트 테이블 하나 (테이블수는 2개)
 
4. 게시판 각각의 게시글 테이블 1개, 코멘트 테이블 1개 (테이블수 = 게시판수 x 2개)
 
5. 기타
|

댓글 26개

데이터규모에 따라...성격에 따라...접속자수에 따라...
범용의 경우입니다.
일반적인 케이스라면 3번이 라고 봅니다.
3번의 경우 제가 생각하는 것은 이렇습니다.

장점이라면
관리가 편하다.

단점이라면
게시글과 코멘트의 통합 검색이 어렵다.
자주사용하지 않는 게시판으로 인한 속도저하(?)가 있을 수 있다.
일단 관리적인 측면을 젤 장점으로 둔거구요.
게시글과 코멘트의 검색은 굳이 같이 갈필요는 없다고 봅니다.

데이타의 양에 따라 결정되어질 문제지만
인덱스만 잘 태운다면 속도 저하는 크게 작용할 문제는 아니라고 보여지는데요.
게시글과 코멘트의 통합검색이 그누보드의 가장 큰 장점이자 DB 부하를 일으키는 주범(?)이죠. ㅠㅠ
하지만 코멘트도 같이 검색되기때문에 정말 편리합니다
커뮤니티에서는..
3번은 일부 게시판에 대해 추가폼을 생성할 경우 불필요한 게시판까지 확장되는 문제점(?)이 있을 수 있겠군요. 3번의 형태로 간다면 외부적인 기능을 잘게 쪼개서 쉽게 추가할 수 있는형태로... 추가필드 같은건 col 형태의 저장이라든가, 어려워지는군요. ;ㅅ;
항상 검색이 문제되는데요
필드확장된것이 검색이 되어야 한다면 위와 언급한 거와 같은 문제점은 있을수 있습니다만, 그게 아니라면 문제없다고 봅니다.

기본적인 여분필드를 통해서 문자열 조합으로 처리할수 있으니까요.
3번으로 하면서 검색을 두개로 한다면 어떨까요.
코멘트 검색은 있지만 본글과 같이 검색은 안되다. 머 이런
두마리 토기를 잡을 수 있지 않을까요.
사용자들이 그런걸 모를겁니다.
검색이 안되면 아 여긴 없나보다 하고 나가게 되겠죠.
제가 생각하는 것은 지금과 같은 게시글+코멘트 검색에 구간검색을 제외하는 것입니다.
사용자들이 그걸 알게 하면 됩니다.
그누보드가 코멘트 검색이 되서 좋다라는 것을 써보지 않고는 모르는 것처럼요.
그 문제는 인터페이스로 해결하는 것이 좋지 않을까 생각합니다.

다른 편법이 하나 있습니다만
검색시 리스트 검색과 코멘트 검색이 따로 따로 되어 나오는 것입니다.

2개의 테이블이 나오는 것이지요.

1. 게시물 검색결과
2. 코멘트 검색결과

편법이라서 쩝... 혹시 이게 아이디어가 될까 해서 남깁니다.
3. 모든 게시판의 게시글 테이블 하나, 모든 게시판의 코멘트 테이블 하나 (테이블수는 2개)

-> 수정.. 실수했군요.. 4번으로 정정 합니다
2222

아직까지 쓰면서 불편한 사항이 없었어요
3번에 테이블1, 코멘트1, 첨부파일1 ... ^^ 이런구조가 좋을듯하네요 ^^
3번
모든 게시판의 게시글 테이블 1개,
모든 게시판의 코멘트 테이블 1개,
모든 게시판의 첨부파일 테이블 1개

게시판 테이블 구조는 킴스큐의 구조가 이상적....
킴스큐RB의 구조 개인적으로 좋아합니다.
두마리 토끼를 다 잡기는 힘들꺼같습니다...
게시판과 댓글 파일 이런식으로 하나씩 만드는 게 괜찬던데요..
저는 4번으로 쓰고 있습니다.
음 3번도 괜찮을거 같은데 3번도 고민해봐야겠군요..........
어느 세월에? 으응?
4번이 괜찮을꺼 같습니다~
개인적으로는 3번을 추천합니다.
전 1번을 선호합니다.

그러나 대용량의 커뮤니티 같은 경우는 디비 분리는 불가피하겠네요..

리자님 께서 범용이라고 하셨으니..
범용의 경우는 1번이 아닐까 생각이 듭니다.
게시판이 수십개가되든 하나의 테이블이면 별문제가 없다고 봅니다.

초기에는 그냥운영하다가..
커뮤니티 크기가 커지고하면 제작의뢰를 하든 어떤방식으로 분리를 하거나 튜닝을 해서 사용하겠죠..

레코드 한두개를 위해서 테이블을 게시판마다 만드는건 좀 낭비라는 생각이 많이듭니다.

아니면 5번 그룹별로 테이블을 생성한다.
도 절충방안이라고 보네요^^
3번이요 -
하루에 방문자수 몇만명은 되는 커뮤니티
table 하나로 소화하고 있습니다.
일단은 3번이요.
추가필드 경우는 추가테이블을 따로 두고 foreign key 를 통해.

하지만, 반드시 게시글과 코멘트 통합검색에 중점을 두신다면
1번이요.
글과 코멘트는 똑같은 포스트라는 개념으로 ;)
댓글을 작성하시려면 로그인이 필요합니다. 로그인

프로그램

+
제목 글쓴이 날짜 조회
14년 전 조회 613
14년 전 조회 731
14년 전 조회 930
14년 전 조회 1,681
14년 전 조회 964
14년 전 조회 913
14년 전 조회 1,639
14년 전 조회 881
14년 전 조회 733
14년 전 조회 743
14년 전 조회 834
14년 전 조회 1,019
14년 전 조회 944
14년 전 조회 996
14년 전 조회 1,106
14년 전 조회 973
14년 전 조회 2,239
14년 전 조회 1,868
14년 전 조회 2,544
14년 전 조회 509
14년 전 조회 809
14년 전 조회 1,072
14년 전 조회 671
14년 전 조회 653
14년 전 조회 1,443
14년 전 조회 1,254
14년 전 조회 2,344
14년 전 조회 1,252
14년 전 조회 852
14년 전 조회 3,368
14년 전 조회 1,592
14년 전 조회 1,007
14년 전 조회 1,367
14년 전 조회 727
14년 전 조회 1,848
14년 전 조회 775
14년 전 조회 1,212
14년 전 조회 721
14년 전 조회 1,253
14년 전 조회 1,488
14년 전 조회 998
14년 전 조회 781
14년 전 조회 1,004
14년 전 조회 935
14년 전 조회 1,954
14년 전 조회 1,123
14년 전 조회 825
14년 전 조회 723
14년 전 조회 1,335
14년 전 조회 2,623
14년 전 조회 716
14년 전 조회 2,545
14년 전 조회 1,662
14년 전 조회 892
14년 전 조회 1,107
14년 전 조회 1,003
14년 전 조회 995
14년 전 조회 511
14년 전 조회 720
14년 전 조회 823
14년 전 조회 1,183
14년 전 조회 881
14년 전 조회 1,240
14년 전 조회 1,022
14년 전 조회 1,123
14년 전 조회 726
14년 전 조회 1,033
14년 전 조회 932
14년 전 조회 807
14년 전 조회 700
14년 전 조회 1,183
14년 전 조회 1,593
14년 전 조회 949
14년 전 조회 786
14년 전 조회 3,321
14년 전 조회 844
14년 전 조회 728
14년 전 조회 2,118
14년 전 조회 1,517
14년 전 조회 2,035
14년 전 조회 604
14년 전 조회 854
14년 전 조회 709
14년 전 조회 549
14년 전 조회 633
14년 전 조회 759
14년 전 조회 1,507
14년 전 조회 864
14년 전 조회 913
14년 전 조회 535
14년 전 조회 1,071
14년 전 조회 1,658
14년 전 조회 1,045
14년 전 조회 1,339
14년 전 조회 852
14년 전 조회 982
14년 전 조회 778
14년 전 조회 1,105
14년 전 조회 1,005
14년 전 조회 425
🐛 버그신고