여기에 적절한 내용인지 모르겠지만, 또 달리 마땅한 곳이 없어서 적어봅니다. 아래에 게시판에 대한 글도 있고 해서...

여러가지 게시판들이 많이 있습니다만 각자 나름대로의 알고리듬을 가지고 게시물들을 관리하리라 생각됩니다. 다른 글들과 달리 게시판은 답글이 달리고 삭제할수도 있고 처리해야 할 일이 많을것 같은데요.

만일 다음과 같은 조건을 만족시키는 게시판을 만들려면 어떤 구조와 알고리듬이 가장 좋을까요?

가. 글에 대한 답글을 달 수 있어야 한다.

나. 게시물을 삭제할 수 있는 기능이 있어야 한다.

다. 게시물을 페이지별로 엑세스할수 있어야 한다.

뭐 기본적인 게시판에 대한 내용입니다...

제가 대충 생각해 본 테이블의 구조는 2가지입니다.

1. 게시물마다 일련 번호를 붙어준다. (즉, primary key가 하나란 말이 되겠네요)

답글이 달리거나 게시물이 삭제되면 모든 게시글의 번호를 갱신(update)시켜준다.

장점 - 페이지 액세스가 간편하고 빠르다. 페이지를 번호별로 액세스하면 되니까요.

단점 - 답글이 달리거나 글 삭제시 전체 테이블에 update문이 쓰이니까 속도가 느리다.

2. 게시글에 번호, 스레드(thread)를 만들어서 사용한다. (즉, primary key가 둘 혹은 그 이상입니다)

답글이 달리면 그 번호내의 게시물들만 처리한다. 삭제시는 그냥 그 글만 지워버린다.

장점 - 답글이 달리거나 글 삭제시 처리 속도가 빠르다.

단점 - 페이지 액세스가 1번보다 느리고 처리가 복잡하다.

제 생각에는 2번의 방식을 쓰는게 좋을 것 같은데요, 만일 2번을 쓴다고 하면 페이지 액세스시 게시물의 갯수를 어떻게 구하는게 좋을까요?

a. 무조건 번호별로 구한다.

첫글에는 번호가 붙어있으니까 그냥 몇번이상, 몇번 이하와 같은 방식으로...

장점 - 처리가 그래도 간단하다.

단점 - 페이지를 볼 때 게시물의 수가 일정하지 않다. (만일 해당 페이지의 게시글이 전부 삭제된다면 빈 페이지도 생길수 있겠네요.)

b. 게시물 액세스시 일일이 계산해서 번호를 액세스한다.

이건 좀 무리가 있을것 같아서 그냥 넘어갑니다.

c. 페이지별 테이블을 따로 만들어서 액세스한다.

처리는 복잡하겠지만 적어도 (게시물 숫자 / 페이지별 게시물 숫자)를 갱신하면 되니까 update 속도, 액세스 속도 둘 다 비교적 만족스러울것 같습니다.

d. 어플리케이션 서버(?)를 따로 만든다.

아예 독립된 프로그램을 짜서 게시물의 번호를 내부적으로 저장하고 있다가 소켓으로 통신해서 자료를 보내준다.

잘만 만들면 좋겠지만 내공이 딸려서 무리일것 같습니다. :)

주절 주절 적어 놓았습니다만 제가 생각한 방법보다 더 좋은 방법이 있을것 같아서 적었습니다.

다른 고수님들의 코멘트나 더 좋은 방법에 대한 가르침 감사히 받겠습니다.