리자

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

 
배포용의 게시판을 말씀 드리는 것입니다.
 
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년 전 조회 612
14년 전 조회 729
14년 전 조회 927
14년 전 조회 1,677
14년 전 조회 962
14년 전 조회 910
14년 전 조회 1,637
14년 전 조회 878
14년 전 조회 730
14년 전 조회 742
14년 전 조회 832
14년 전 조회 1,018
14년 전 조회 941
14년 전 조회 992
14년 전 조회 1,105
14년 전 조회 972
14년 전 조회 2,236
14년 전 조회 1,865
14년 전 조회 2,539
14년 전 조회 507
14년 전 조회 805
14년 전 조회 1,069
14년 전 조회 667
14년 전 조회 651
14년 전 조회 1,441
14년 전 조회 1,251
14년 전 조회 2,343
14년 전 조회 1,252
14년 전 조회 850
14년 전 조회 3,364
14년 전 조회 1,591
14년 전 조회 1,007
14년 전 조회 1,365
14년 전 조회 726
14년 전 조회 1,846
14년 전 조회 775
14년 전 조회 1,210
14년 전 조회 719
14년 전 조회 1,250
14년 전 조회 1,487
14년 전 조회 995
14년 전 조회 779
14년 전 조회 1,001
14년 전 조회 934
14년 전 조회 1,951
14년 전 조회 1,122
14년 전 조회 825
14년 전 조회 721
14년 전 조회 1,333
14년 전 조회 2,620
14년 전 조회 714
14년 전 조회 2,544
14년 전 조회 1,660
14년 전 조회 891
14년 전 조회 1,106
14년 전 조회 1,001
14년 전 조회 995
14년 전 조회 509
14년 전 조회 717
14년 전 조회 821
14년 전 조회 1,182
14년 전 조회 880
14년 전 조회 1,238
14년 전 조회 1,020
14년 전 조회 1,123
14년 전 조회 725
14년 전 조회 1,031
14년 전 조회 931
14년 전 조회 806
14년 전 조회 699
14년 전 조회 1,182
14년 전 조회 1,592
14년 전 조회 945
14년 전 조회 786
14년 전 조회 3,320
14년 전 조회 843
14년 전 조회 727
14년 전 조회 2,117
14년 전 조회 1,516
14년 전 조회 2,034
14년 전 조회 601
14년 전 조회 852
14년 전 조회 708
14년 전 조회 548
14년 전 조회 633
14년 전 조회 759
14년 전 조회 1,506
14년 전 조회 863
14년 전 조회 913
14년 전 조회 535
14년 전 조회 1,066
14년 전 조회 1,658
14년 전 조회 1,045
14년 전 조회 1,334
14년 전 조회 850
14년 전 조회 981
14년 전 조회 775
14년 전 조회 1,101
14년 전 조회 1,004
14년 전 조회 424
🐛 버그신고