소스를 분석하다보면, XE 제작자분들이 참 여러 고민을 하셨다는 것을 알 수 있네요

 

게시글 이동, 게시글 복사, 카테고리 변경/이동/삭제,  일괄삭제 기능등..

이용에 편리한 기능들이.... 

이 편의성 때문에 애매한 경우의 수 들이 생기다보니...

소스를 드여다보면,  카운트를 안 하고  그때그때 총 수를 검색하는 쿼리문들이 생겨나네요

 

잘 알려져있는 대표적인 문제점이..

게시글 전체가 몇개인지 목록 좌측상단에 보통 출력하는데..

이게  DB안에서 총 수를 저장하지 않고..   그때그때 해당 게시판의 총 글 수를  count(*)로 일일이 읽어내고 있죠

글 수가 많을 수록 이 부분이 부하가 되어 굉장히 부담이 된다는건 잘 알려져있죠

 

sequence table 처럼,  일일이 카운트를 하면 좋긴한데..

여러 상황에 정밀하게 대처가 되어야하는데   여러 편의 기능들때문에, 불안해서인지..

그냥 그때그때 세어 보게 되어있네요

 

속도 문제의 핵심사항중 하나인 부분인데..

(혹자는 이를 캐시로  처리해 부담을 줄이지만,  그러면 결국 숫자가 정밀하게 안 맞죠..^^;)

 

흠.. 그래도  모든 상황을 잘 조절해서  DB에 이 값을 저장해두는게 더 좋다고 보는데

과연 이 부분이 변경이 될 수 있을지 모르겠네요

 

 

 

아..  제가 하고픈 얘기는  이런 문제점이.....    이 총 글 수 외에..

카테고리 기능을 사용하는 경우,  글 등록시에도 발생한다는거예요 

 리스트 등의 화면등에서는 상관이 없어요.  실제 등록시 문제가 되는 부분인데.. 

 

카테고리의 수를 변경하는 기능들이...

실제로  getCategoryDocument.xml  을 통해 등록된 글 전체에서 해당 카테고리에 해당되는 글의 총 수를 그때그때 파악해

DB의 category 수 항목에 입력되게 되어있어요

 

DB에 category의 글수 항목이 따로 있길레,  포인트 처럼

당연히  DB에서 해당 카테고리의 글 수 항목을 불러들여, 여기서 +1 / -1  또는 이동시 + 여러개 해 저장할거라 생각했는데

글 등록시 / 카테고리 변경하는 글 수정시 / 글삭제시마다..

항상 DB전체에서 해당 카테고리의 글 수가 몇개인지 count(*) 로 찾아낸 다음에  insert 를 하든 update 를 하게 되어있네요 ^^;;

 

흠...   결국 위와 마찬가지 문제인데.. 참 애매한 부분이예요

point 처럼  전부  +1  /  -1  이런 개념으로 변경하면  속도에 도움이 될텐데 싶어서요..

 

 

 

ps.  제가 작업하다가,  공지글을 전부 제외시키는 기능을 만들고 있었거든요

      즉, 공지글은 목록에도 안 나오고,  카테고리 수에도 포함이 안 되고,  총 글 수에도 포함 안 되고..

      (확인하고플땐, 공지글 예외 체크를 해지해, 목록상에서만 볼 수 있게..)

      이게 은근히 까다롭네요 ^^;;;