대상 : ASP.NET을 이용하여 스스로 일반 게시판이 작성가능하거나,
         Taeyo's ASP.NET v1.0 서적을 통해서 게시판 만들기를 이미 공부하신 분

이번에는 말입니다. 계층형 게시판을 ASP.NET으로 구현해볼까 합니다.

계층형 게시판을 만들기 위해서는 무엇보다 먼저, 계층형 게시판의 동작하는 로직을 이해하는 것이 중요합니다.(이미 ASP 시절에 계층형 게시판, 답변형 게시판을 만들어 보신 분들은 이 말을 인정하실 겁니다) 이 로직은 한번 정립되면 ASP.NET 뿐 아니라, ASP에서도, JSP에서도 그 어디에서도 동일하게 사용이 가능한 것이니까요. 사실, 이러한 로직을 이해하고 나면 실제로 계층형 게시판을 구현하는 것은 사실 크게 어렵지 않습니다. 일반 게시판의 것과 다를 것이 없지요. 나중에 모두 공부를 하고 나시면 알겠지만, 계층형 게시판이라는 것도 로직과 Query만이 조금 다를 뿐, 일반 게시판과 대동소이 하답니다.

그리고! 이 로직을 여러분이 쿼리로 모두 작성해 놓는다면, 그 쿼리는 여러분이 계층형 게시판을 구현하고 싶은 그 어디서도 동일한 방법으로 사용이 가능합니다. 윈도우즈 VB 어플리케이션에서도, JSP 웹 어플리케이션에서도, .NET에서도, 그리고 그 어디서도 말입니다.

OK! 이제 논리적인 로직을 이해하는 것이 왜 필요하고, 왜 중요한지 조금은 감을 잡으신 것 같네요. 그럼 시작해 보도록 하겠습니다.

근데요. 이 계층형 로직에 대한 설명은 제 사이트의 ASP.NET 시삽이시면서 얼마전 정보문화사에서 'New 알기 쉬운 ASP.NET'을 출판한 캐싸트님의 글을 빌어서 편집하여 보여드리려 합니다. 그 분의 글이 제가 보기에는 지금까지 계층형 로직을 설명해 놓은 그 어떤 글보다도 너무나도 정리가 잘 되어 있어서리.... 개인적으로 협조를 좀 구했거든요.(해당챕터의 원고를 통채로 주더군요. 역시 통큰 캐싸트!) 해서, 그 분의 글을 제가 재 정리하면서, 약간의 편집을 통해 강좌를 올려보려 합니다.

'그래서? 무슨 말이 하고픈 거냐?'고 물으신다면, '캐싸트.. 고마워'라는 말을 쓰고 싶었더라는 거랍니다. ^^

그럼 이제 시작해 볼까요?

1. 계층형 로직

계층형 게시판은 하나의 글에 트리 형태로 다른 사람이 답변을 달 수 있는 구조입니다. '답변형', '계층형' 혹은 '쓰레드형'이라고도 부르죠. 그러니깐, 예를 들면 다음과 같은 구조의 게시판을 계층형 게시판이라고 부른다는 겁니다. ^^

계층형 게시판은 이처럼 트리 형태로, 윈도우즈 탐색기에서 폴더를 펼쳐서 볼때와 비슷한 형태로 글에 답변을 할 수 있습니다. 하지만, 이 게시판은 사용하는 사람 입장에선 좋은데, 이러한 모습이 되도록 개발하는 것에는 좀 번거롭고, 피곤한 여러 가지 로직이 필요하답니다.

번거롭게 이런 저런 로직이 필요한 이유는 우선 첫번째는, 데이터베이스가 트리형 구조를 나타낼 수 있는 SQL 구문을 잘 지원하지 않기 때문이구요. 두번째는 속도 문제 때문입다. ORACLE의 경우엔 select 문에 start with ... connect by 라는 구문으로 트리 구조를 지원하지만, 다른 데이터베이스들 - MS SQL, Access, MySQL 등 - 은 지원하지 않기 때문이죠.

그리고, 설사 트리 구조를 만들어 보여주는 기능이 있다 해도 속도/효율성 때문에 ORACLE에서도 다른 로직을 쓰곤 한답니다(들은 이야기입니다 -_-+). 해서, 이러한 계층형 게시판을 효율적으로 작성하기 위한 여러가지 로직들이 발표(?)되고 있구요. 지금도 새로운 로직들이 고민되고 있기도 하지요.

계층형 게시판을 구현하기 위한 로직에는 여러가지가 있을 수 있겠지만, 여기서는 그 중 보편적으로 알려진 세 가지를 살펴보도록 하겠습니다. 그리고, 언제나 스타는 마지막에 등장하기에 세 가지 중 마지막 로직을 채택해서 강좌는 진행해 보도록 하겠습니다.

- 단순 업데이트형

예전에 많이 쓰였던 비교적 간단한 형태의 계층형 로직을 생각하자면, 글에 답변 달 때 그 위치 위(혹은 아래)의 모든 글이 한칸씩 이동하도록 하면 됩니다. 예를 들면, 글을 쓸 때마다 일련번호를 주고, 2번글에 답변을 달면, 2번 윗글은 글번호를 모두 하나씩 더해 주구요(즉 2->3, 3->4, update 문을 이용하면 한번의 쿼리로 이것이 가능하죠). 그리고 답변글에 2라는 번호를 주면 되는 방법이었습니다(사실, 지금 생각하면상당히 무식한 방법이었죠 *ㅛ*). 다음은 그 방법으로 구현할 경우를 보여주고 있습니다

질문글만 올라온 경우

답변이 달리는 경우

글번호	제목
4	세번째로 올라온 글
3	두번째로 올라온 글
2	두번째 글의 답변으로 올라온 글
1	첫번째로 올라온 글

이 방식은 ASP 초기에 조금 쓰였던 방법이었습니다. 그런데, 만약 글이 1만개 인데, 마지막 글에 답변을 한다고 생각해 보세요. 그러면 첫 번째글부터 마지막 글까지 1만개 레코드에 글번호를 1씩 더해주어야만 했습니다. 1만개의 레코드를 바꾸는 것은 아무리 빠른 컴퓨터라 해도 몇 초가 걸릴 수 있어요.(웹에서 몇 초는 대단히 중요합니다. 백 명이 동시 접속한다면 이론적으로 몇 백초가 걸리는 정도의 부하가 발생하기 때문이지요) 해서, 현재는 이 방법을 그다지 추천하지 않고 있답니다. ㅠ_ㅠ

이와 같은 로직은 레코드를 추가 할때마다, 그 순서를 update문으로 바꾸기 때문에 '업데이트형'이라고 보통 불려지고 있습니다. 1만개의 글에, 마지막에 답변할 사람은 거의 없기때문에, 이 로직을 이용한다고 게시판이 매우 느려지는 것은 사실 아닙니다. 보통 최근 글에 답변하기 때문에, 많은 행이 업데이트 되진 않는 것이지요. 하지만, 어쨌든 비효율적인 것은 사실인지라, 최근에는 위와 같은 로직은 거의 사용하지 않고 대신 일부만 업데이트하는 방식을 사용하고 있습니다. 현재 태오 사이트가 사용하는 방식도 그런 방식이지요. 그리고, 우리의 게시판에 사용할 로직도 그것이구요 ^^. 이 로직은 잠시 뒤에 보여드리도록 하겠습니다

- 비 업데이트형 (문자열 형식 사용)

일부 게시판 (특히 PHP나 JSP 게시판)은 문자열(varchar) 형으로 트리 형태를 나타내는 필드를 하나두어 답변형 게시판을 구현하기도 했습니다다.

즉, 문자열 필드("답변모양" 필드라고 잠시 불러보도록 하겠습니다)는 주(root) 글이면 빈 문자열인데, 답변이 달릴 때마다 a,b,c,d ...형태로 글자(편의상 알파벳으로 설명)로 번호를 메깁니다. 해당 글의 답변에 대해선 그에 덧붙여서 a,b,c,d ... 식으로 글자를 추가하구 말이죠. 예를 들면, 다음처럼 말입니다.

글번호	답변모양	제목
3		세번째로 올라온 글
2		두번째로 올라온 글
2	a	두번째로 올라온 글의 답변
2	aa	두번째로 올라온 글의 답변의 답변
2	aaa	두번째로 올라온 글의 답변의 답변의 답변
2	ab	두번째로 올라온 글의 답변2
1		첫번째로 올라온 글

이 방식에선 답변할 때 업데이트가 필요없어요. 예를 들어, 위의 답변형 형태에서 "두번째로 올라온 글의 답변의 답변"에 답변한다면, 글 번호가 2이고, "답변모양"이 "aa"로 시작하는 것의 최대값을 찾구요(위에서는 "aaa"). 그리고, 찾은 "답변모양" 필드의 마지막 글자에 +1 - 즉 "aab" - 해서 그 값으로 레코드를 삽입하는 것이죠. 아마도, "글번호"와 "답변모양"을 합쳐서 인덱스(혹은 기본키)를 주었을 것이므로(꼭 인덱스를 주어야 합니다) 최대값을 찾는 것은 매우 빠를 것입니다.목록보기에선 글번호 역순(desc), 답변모양 제순서(asc)로 레코드를 가져오면 되구요( select ... order by 글번호 desc, 답변모양 asc )

이러한 방식에선 답변할 때 업데이트가 필요 없으니, 답변하는 것이 매우 빠르답니다. 단점이라면 varchar 형 필드가 필요해서 글 목록 부분에서 약간 느려질 수 있다는 것(사실, 이것은 DB에 따라 다릅니다. MS SQL이라면 거의 차이가 없을 것 같네요), 그리고 약간의 추가 공간이 필요하다는 정도이랍니다. 해서, 사실 이 방법도 그리 나쁜 방법은 아니랍니다.

- 일부 업데이트형. 이 게시판의 로직

하지만, 우리가 같이할 방법은 위와는 조금 다른 방법입니다. 약간의 제한을 사용해서 오히려 성능을 높이게 하는 방법을 채택하려 한답니다.해서, 우리가 제작할 게시판에서는 하나의 글에 답변할 수 있는 글의 수에 제한을 두었습니다(성능을 고려한 설정이지요~). 설명을 위해 편의상 1000 개로 한다고 해보자구요. 그리고, 글번호(예제 게시판에선 thread라는 필드로 되어있습니다)를 띄엄띄엄, 그 수만큼, 즉 1000 단위로 주게 하는 겁니다. 다음처럼 말이죠

그리고, 답변이 달리는 경우는 각 글별로 업데이트를 해서 정렬하게 할 것입니다. 즉, 글번호가 2000번인 녀석의 하위로 답변이 달리면 그넘들의 글 번호는 1999, 1998, 1997... 이렇게 주어지게 되는 것이구요. 총 999 개의 답변이 달릴 수가 있게 되는 것이죠. 1000개로 답변을 제한한다는 제약이 있기는 하지만, 저는 아직까지 사이트를 운영하면서 하나의 글에 999개의 답변이 달리는 경우는 보지 못했습니다. 심지어는 99개의 답변이 달리는 경우도 보지 못했습니다. 물론, 예전 "죠리퐁 댓글"과 같이 하나의 글에 엄청난 갯수의 댓글이 달리는 것은 본적이 있지만, 그것은 답변이 아닌 댓글(커멘트)였기에 여전히 큰 문제가 되지 않지요.

이제, 위에서 두 번째 글에 답변을 한다고 생각해 보세요. 그러면, 원래 그 글밑에 답변으로 달려져 있던 글들을 즉, 글번호가 1999~1000 사이인 글의 글번호를 하나씩 줄여 나가게 합니다. (지금은 레코드가 없어서 업데이트 되는 행은 물론 없겠죠) 그리고, 새로 들어오는 글의 번호를 1999번으로 해서 레코드를 추가하면 두번째 글과 세번째 글 사이에 글이 추가되게 되는 것입니다. 어렵나요? 나중에 실제 예를 보면 이해가 그리 어렵지는 않을 것입니다.

그런데 어느 글이 주(root) 글인지 답변인지, 답변이라면 어느 글에 대한 것인지는 어떻게 구분할 수 있을까요? 그것은 글 별로, 글이 몇 단계 째인지를 나타내는 필드를 두면 됩니다. 즉, 주 글은 0, 주 글에 대한 답변이라면 1, 답변에 대한 답변이면 2와 같은 식으로 값을 주면, 그 수만큼 제목 왼쪽을 띄어쓰기 해서 답변 달린 모습으로 만들 수 있게 되는 것이죠. 우리가 제작할 게시판에선 이러한 목적의 컬럼이 depth라는 이름의 필드로 되어있습니다. 그래서글을 추가하면 다음과 같은 모습이 되어지는 것이지요.

글번호(thread)	depth	제목
3000	0	세번째로 올라온 글
2000	0	두번째로 올라온 글
1999	1	두번째로 올라온 글의 답변1
1000	0	첫번째로 올라온 글

글을추가할 때마다 같은 방식으로 하고, 목록을 보여줄때는 글번호를 기준으로 역순으로 정렬을 하면 순서대로 계층적으로 보여지게 됩니다. 그리고, depth 가 0 이상인 경우 (주 글이 아닌) 답변 글이니, 그 depth 수 만큼 왼쪽에 공간을 두어 답변을 표시하면 우리가 기대한 대로 화면을 출력할 수 있게 되는 것이죠. 같은 방식으로 여러 행을 답변하면 어떻게 될지 생각해 보세요.

글번호(thread)	depth	제목
3000	0	세번째로 올라온 글
2000	0	두번째로 올라온 글
1999	1	두번째로 올라온 글의 답변2
1998	2	두번째로 올라온 글의 답변의 답변2
1997	1	두번째로 올라온 글의 답변1
1000	0	첫번째로 올라온 글

이처럼, 중간에 갭을 두어서, 중간 부분만 업데이트하면 됩니다.(설명이 좀 어려운가요??) 예를 들면, 여기서 "두번째로 올라온 글의 답변2"에 답변을 단다면 1001~1998 사이에 있는 두개의 레코드가 업데이트 되어 한칸씩 뒤로 물러나게 한다는 것입니다(자기가 들어갈 자리보다 높은 번호를 가진 글들은 업데이트를 할 필요가 없겠죠? 예를 들면, 지금의 경우는1998 번보다 높은 글들은 업데이트를 할 필요가 없다는 겁니다). 다시 말해서, 자신의 글번호보다 낮은 글번호들 중 1000보다는 글번호가 큰 것들만 업데이트 한다는 것이지요. 그리고, 새로운 답변글은 1998라는 번호를 갖게 되고, depth 는 2가 된다는 것입니다. depth는 답변을 달 글의 depth에 하나를 더한 값으로 계산해 주면 되는 것이죠.

참고로, 잘 보면 우리의 게시판에서는 답변할 경우, 최근에 달리는 답변이 밑으로 놓여지는 것을 볼 수가 있습니다. 즉, 우리의 예상대로라면 "두번째로 올라온 글의 답변1"이라는 답변이 "두번째로 올라온 글의 답변2"보다 위에 있어야 할 것 같은데 밑에 놓여졌다는 것이지요. 이 부분을 이상하게 생각하시는 분들이 많은데요. 어떤 식으로 출력되느냐는 생각의 차이인 것 같습니다. 예전 크레이지 보드나 기존 보드들은 대부분 지금 제가 제작하는 것과 같은 형태로 제작되었었습니다. 현재는 두 가지의 방식이 뒤섞여서 존재하고 있기도 하지만 말입니다... 사실, 이 부분을 여러분이 원하시는 대로 바꿀 수 없는 것은 아닙니다만... 그렇게 할 경우, 데이터베이스에 조금은 많은 부하를 주게 되기에, 특별히 사용상에 불편함이 없다면 제가 제시하는 방법대로 진행하시는 것이 성능에 도움이 될 것입니다. 해서, 요즘 대부분의 보드들은 이와같은 방식으로 제작된답니다. 제 사이트의 게시판도 물론 그렇지요 ^^.

어쨋든 이번 로직은 첫 번째로 소개한 로직에 비해서 업데이트하는 양이 대폭 감소한 것을 알 수 있습니다. 100만개의 글이있다 쳐도, 그 글에 속한 답변만 업데이트하면 되니까요. 우리의 경우라면 하나의 답변이 달릴 경우 최대 999개만 업데이트 하면 되겠죠? 물론, 이 방식도 하나의 글에 예컨대 500개의 답변이 달려있는 경우라면 비효율적일 수 있습니다. (최대 500개의 레코드를 업데이트 해야하므로) 그러나,

1) 답변이 그렇게 많이 달리는 일은 거의 없습니다다.
    아무리 활성화 된 게시판이라 해도 많아야 10개, 보통은 1~2개의 답변이 달립니다다.
2) 답변을 다는 일은 게시판 목록을 보는 것보다 빈도수가 적습니다. 
    약 1/10 이내일 듯 하기에, 그렇다면 목록 보는 쪽에서 속도를 낼 수 있도록 설계하는 것이 낫습니다.

해서, 이 방법이 비교적 쓸만한 방법이라고 제시하는 것이랍니다.
(물론 이 방법이 최선의 로직은 아닙니다. 실제 몇 만명이 접속하는 커뮤니티 사이트에서라면 이보다는 훨씬 개선된 로직이 필요할 것 같습니다. 그런 경우는 전문가들과 상의해 보세요...  ㅠ_ㅠ)

위에서 설명했던 두 번째 로직(비 업데이트 형)의 경우는 컬럼의 타입을 varchar로 하는데, 이는 목록보기에서 약간은 속도 저하가 있을 수 있습니다. (상황에 따라, 데이터베이스에 따라 다르긴 합니다만) 한편, 이 로직은 int 형 필드 하나로 정렬하기 때문에, 업데이트하는 약간의 속도저하는 목록에서 충분히 커버를 할 수가 있다고 봅니다. 어쨌든, 약간의 속도저하라는 것도, 제 컴퓨터에서 테스트해보면 100행을 업데이트하는 것이 0.01초면 실행이 끝나죠. (MS SQL 2000에서 30만건 레코드, 앞/뒤 여러 부분에서 100행씩 업데이트하는 구문을 100번 실행해서 테스트했는데 약 1초가 소요되었습니다. 물론, Access는 그보다는 약간 느릴 것 같네요)

Listing 페이지에서의 페이징 로직

일반적으로 게시판은 페이징 기능을 사용해서 글의 일부를 페이지 별로 보여주게 됩니다. 만일, 게시판에서 페이징 기능을 제공해 주지 않는다면 아마도 한 페이지가 밑으로 너무 길어져서리 사용자들이 불만의 폭탄을 난사할지도 모릅니다.

어쨋든, 게시판이 페이지 당 20개의 글을 보여준다면 첫 페이지에서는 첫번째 글부터 20번째 글, 두번째 페이지는 21~40번째 글, 100페이지는 2001~2020번째글을 보여주어야 할 것입니다. 사실  ASP.NET에서 이것은 DataGrid에서 지원하는 페이징(자동 페이징이라 부르겠습니다)을 사용하면 비교적 간단하게 구현할 수가 있습니다.(제 책에서도 다루었었죠?) 그렇지만, 제 Taeyo's ASP.NET v1.0(간만에 광고!)에서도 언급했듯이 그 방식은 전체 레코드를 가져와서, 그 중 일부만을 출력해 주는 방식입니다. 해서, 게시물의 데이터 수가 많지 않는 경우에만 추천한다고 말씀을 드렸었죠. 

이러한 문제는 ASP에서도 비슷한 문제가 있었습니다. 레코드를 가져올때는 레코드셋 개체를 쓰는데, 그 레코드셋 객체 자체에 페이징할 수 있는 기능이 이미 들어있었죠. 그러나, 그 기능을 이용하게 되면 레코드가 많아지면 매우 느려졌었습니다. 예를 들어, 1만 개의 글 중 첫페이지를 본다 해도, 우선 1만개의 레코드를 데이터베이스로부터 모두 ASP의 메모리로 가져오고, 그리고 난 다음에 그 중 첫 페이지 부분인 20개의 레코드만을 사용하게 되는 것이었으니까요. 어때요? 메모리의 낭비가 파바박!! 느껴지는 매우 비효율적인 방법임을 알 수 있죠? 원래가 그렇습니다. 개발자가 사용하기 쉬운 방법은 대부분 성능에는 좋지 않은 방법이고는 하는 것이죠 해서, 그런 말이 있잖습니까? 개발자가 조금만 더 피곤하면 더 좋은 소프트웨어가 나온다. (그런 말 없나요??? -ㅛ-)

어쨋든, 그러한 문제는 ASP.NET에서도 마찬가지로 남아있습니다. 그래서 제 사이트의 게시판 강좌들에서는, Top 로직을 써서리 원하는 페이지에 해당하는 글만을 가져오는 방식을 사용했었습니다. ASP.NET은 빠르고, 데이터베이스도 빠르고, 컴퓨터도 빠르기 때문에, 1만개 이내의 글이 등록된 게시판이라면 '자동 페이징'을 쓰던, '수동 페이징'을 쓰던 어떠한 방식을 사용한다 해도 큰 차이는 못 느낄 수 있습니다. 그러나 10만개 이상되면 로직에 따라 수배 내지 수십배의 차이가 날 수 있고, 1만개 이내라 해도 게시판이 여러 개라면, 혹은 동시 접속자가 많다면 마찬가지입니다. 그래서 이 로직을 제시한 캐싸트님은 여러 방식을 시험해 보고 속도를 재보았고, 그 결과 다음과 같은 쿼리 문으로, 일부만 추출해 내는 것이 그가 해본 방법 중 제일 빠르다는 결론에 이르렀습지요.(수고했습니다. 캐싸트) 물론, 이 쿼리는 제한된 경험에 한정된 것이기에, 더 좋은 방법은 얼마든지 있을 수 있다는 것은 두말할 필요가 없답니다... (여러분의 머리를 믿어보세요 ^^ 그리고, 도전하세요~~)

만약, 게시판(테이블이름 board)의 글이 thread라는 필드를 기준으로 역순으로 정렬되고(위에서 제시한 방법이며, 그리고 우리가 제작한 방법이기도 합니다), 레코드중에서 1000번째 부터 20개를 가져온다면, 다음과 같은 쿼리문을 사용할 수 있습니다.

select * from board
where thread in
         ( select top 20 thread from
                  ( select top 1020 thread from board
                    order by thread desc ) as a
           order by thread asc )
order by thread desc

서브쿼리를 사용하여 다소 복잡해진 모습이기는 합니다. 하지만, 기존 태오의 일반 게시판에서의 페이징 방법을 공부한 다음, 골똘하게 생각해 보신다면 그리 어려운 쿼리는 아닙니다. 이러한 쿼리가 어떻게 작성되었는지는 설명드리기 쉽지 않네요. 제가 데이터베이스를 전문적으로 하는 사람도 아니어서, 설명력이 부족해서요... ^^; 이 시점에서 여러분의 개인적인 노력이 필요합니다. ^^. 만일 쿼리가 이해가 잘 되지 않는다면 그냥 이런 쿼리를 사용하면 된다고만 인식하시고 넘어가도 됩니다. 사실, 이러한 계층형 쿼리를 반드시 이해해야만 하는 것은 아닙니다. 우리가 프로그래밍 하면서도 모든 것을 이해하고 프로그래밍을 하진 않듯이 말입니다. ADO 같은 것이 그렇죠? 내부적으로 어떻게 동작하는 지는 모르지만, 우리는 그것의 사용법을 배워서 그것을 사용하는 데에 집중해 왔듯이, 이러한 쿼리도 어떻게 동작하는 지 몰라도 사용하는 데에는 문제가 없습니다. 물론, 이해하고 사용하면 더욱 효과적으로 사용할 수 있긴 할 것입니다만 말입니다. 모든 것을 다 알고자 너무 많은 시간을 허비할 필요는 없다는 것이죠 ^^ (한마디로 프로그래밍 하면서 너무 많은 부담을 가지시지는 말라는 말씀을 드리고 싶었습니다.)

그래도, 어느 정도 쿼리에 대한 공부가 되신 분들을 위해서 간단하게만 설명하면, 위의 쿼리는 우선 역순( desc )으로 앞에서부터 1020개를 끊어오고, 그것을 다시 제 순서( asc )로 정렬한 다음, 앞에서부터 20개를 가져옵니다. 그러면, 1000번째 레코드 위치에서부터 20개를 가져오게 되지요. 여기까지가 서브쿼리 구역의 결과이지요. 그리고 난 다음에, 그 레코드에 해당하는 필드들을 다시 역순으로 가져오는 것입니다. 그러면, 우리가 원한 20개의 레코드를 원하는 정렬상태로 가져올 수 있게 되는 것이죠.

물론, 위의 쿼리문은 MS-SQL이나 Access에서만 가능하며, 다른 데이터베이스에서는 불가능합니다. select 문에 사용된 top 구문이 MS 데이터베이스 특유의 것이기 때문입니다. 다만 MY SQL이라면 limit 구문을 이용할 수 있기 때문에 이렇게 복잡하게 할 필요가 없겠고, Oracle은 rownum을 이용해서 비슷하게 할 수 있을 것이긴 합니다.

이번 강좌는 여기까지 입니다. 강좌는 앞으로 한 주에 하나씩 올라올 예정이구요. 테이블의 설계와 실제적인 게시판의 제작은 다음 주부터 이어질 예정입니다.

그럼 다음주에 뵐께요. 좋은 하루 되세요.