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