게시판 테이블 구조로 적당한 것은?
배포용의 게시판을 말씀 드리는 것입니다.
1. 모든 게시판의 게시글과 코멘트를 하나의 테이블로 가져감 (테이블수는 1개)
2. 지금의 그누보드와 같이 게시판 별로 게시글과 코멘트를 하나의 테이블로 가져감 (테이블수 = 게시판수)
3. 모든 게시판의 게시글 테이블 하나, 모든 게시판의 코멘트 테이블 하나 (테이블수는 2개)
4. 게시판 각각의 게시글 테이블 1개, 코멘트 테이블 1개 (테이블수 = 게시판수 x 2개)
5. 기타
|
댓글 작성
댓글을 작성하시려면 로그인이 필요합니다.
로그인하기
댓글 26개
장점이라면
관리가 편하다.
단점이라면
게시글과 코멘트의 통합 검색이 어렵다.
자주사용하지 않는 게시판으로 인한 속도저하(?)가 있을 수 있다.
게시글과 코멘트의 검색은 굳이 같이 갈필요는 없다고 봅니다.
데이타의 양에 따라 결정되어질 문제지만
인덱스만 잘 태운다면 속도 저하는 크게 작용할 문제는 아니라고 보여지는데요.
커뮤니티에서는..
필드확장된것이 검색이 되어야 한다면 위와 언급한 거와 같은 문제점은 있을수 있습니다만, 그게 아니라면 문제없다고 봅니다.
기본적인 여분필드를 통해서 문자열 조합으로 처리할수 있으니까요.
코멘트 검색은 있지만 본글과 같이 검색은 안되다. 머 이런
두마리 토기를 잡을 수 있지 않을까요.
검색이 안되면 아 여긴 없나보다 하고 나가게 되겠죠.
제가 생각하는 것은 지금과 같은 게시글+코멘트 검색에 구간검색을 제외하는 것입니다.
그누보드가 코멘트 검색이 되서 좋다라는 것을 써보지 않고는 모르는 것처럼요.
그 문제는 인터페이스로 해결하는 것이 좋지 않을까 생각합니다.
다른 편법이 하나 있습니다만
검색시 리스트 검색과 코멘트 검색이 따로 따로 되어 나오는 것입니다.
2개의 테이블이 나오는 것이지요.
1. 게시물 검색결과
2. 코멘트 검색결과
편법이라서 쩝... 혹시 이게 아이디어가 될까 해서 남깁니다.
-> 수정.. 실수했군요.. 4번으로 정정 합니다
아직까지 쓰면서 불편한 사항이 없었어요
모든 게시판의 게시글 테이블 1개,
모든 게시판의 코멘트 테이블 1개,
모든 게시판의 첨부파일 테이블 1개
게시판 테이블 구조는 킴스큐의 구조가 이상적....
어느 세월에? 으응?
그러나 대용량의 커뮤니티 같은 경우는 디비 분리는 불가피하겠네요..
리자님 께서 범용이라고 하셨으니..
범용의 경우는 1번이 아닐까 생각이 듭니다.
게시판이 수십개가되든 하나의 테이블이면 별문제가 없다고 봅니다.
초기에는 그냥운영하다가..
커뮤니티 크기가 커지고하면 제작의뢰를 하든 어떤방식으로 분리를 하거나 튜닝을 해서 사용하겠죠..
레코드 한두개를 위해서 테이블을 게시판마다 만드는건 좀 낭비라는 생각이 많이듭니다.
아니면 5번 그룹별로 테이블을 생성한다.
도 절충방안이라고 보네요^^
하루에 방문자수 몇만명은 되는 커뮤니티
table 하나로 소화하고 있습니다.
추가필드 경우는 추가테이블을 따로 두고 foreign key 를 통해.
하지만, 반드시 게시글과 코멘트 통합검색에 중점을 두신다면
1번이요.
글과 코멘트는 똑같은 포스트라는 개념으로 ;)