이 문서는 영양가가 별로 없는 참고자료일 뿐입니다. 개인적인 참고를 위한 메모.. 정도겠네요.. ^^;;;
문득 생각나서 DB구조를 뒤져본 결과에 대한 참고, 혹은 레포팅을 담고 있습니다. DB스키마 만을 보면서 예측한 거라 예측이 정확할지에 대해서는 장담할 수 없습니다.. ^^;;;;;



1. 게시물이 저장되는 테이블의 위치

-> xe_documents 테이블에서 모든 게시물의 제목, 내용을 저장하고 관리합니다. 여기에는 해당 게시물이 소속되는 게시판아이디인 module_srl이 숫자로 기록되어 있네요.
(아마도 외부에 노출되는 값 중 하나인 mid와의 매칭을 위한 기본키의 목적으로 추측됩니다)

-> xe_modules 테이블에서 전항의 module_srl과 mid를 매칭해주는 구조를 가지고 있습니다.


2. 페이지모듈과의 연관성

-> 위키모듈에서 작성되는 문서는 모두 고유의 URL을 가져야 할 것으로 생각됩니다. 많은 종류의 위키(혹은 클론)들이 모든 문서에 고유의 URL을 부여하는데, (예: noname.com/wiki/문서이름) 이것은 문서간의 연결을 더욱 쉽게 하기 위한 목적으로 생각됩니다. 물론 [wiki:문서이름]과 같은 형태의 위키태그또한 존재합니다만..

-> 페이지 모듈을 통해 만들어지는 페이지는 고유의 URL을 가집니다. 이것이 제 1항에서 언급된 xe_modules를 통해 xe_documents테이블을 호출하게 되는 구조입니다. 즉, 페이지의 이름이 mid로 사용되고 이것을 ZBXE의 프레임웍에서 'mid'라는 명시 없이도 불러올 수 있게 하는.. (물론 rewrite_mod가 fancy url을 지원해주는 경우에 한정됩니다만..)


3. 잠재적 문제점

-> 위키모듈이 페이지모듈에서 사용되는 형식의 호출구조를 그대로 이용하는 경우 잠재적인 문제가 있을것으로 추측됩니다. 제 2항에서 언급한 데로 위키모듈을 통해 생성되는 컨텐츠 페이지가 모두 각각의 URL을 부여받고, 이것이 페이지모듈에서 페이지를 호출하는 테이블 구조를 그대로 이용하도록 만들어진다면, 위키모듈을 통해 만들어지는 페이지의 숫자가 늘어날수록 xe_modules테이블의의 부하가 많아질것으로 예측됩니다. 이것은 페이지모듈 자체적으로도 가지고 있는 잠재적인 문제로 보입니다.

-> 별도의 구조를 만드는 경우 또한 명시적인 문제를 야기시킵니다. 이것은 ZBXE의 코어에 관련된 부분입니다.
--> 별도의 호출구조를 만든다면 ZBXE의 페이지 호출구조를 무시하게 되며, 이것은 차후 통일성을 저해하며 위키모듈이 ZBXE의 하부모듈이 되는 형태를 위반하게 될 것으로 예측됩니다. (뜨거운 감자: 별도로 페이지네임을 관리하는 테이블을 가진다면 이 부분을 고민할 필요는 없을것 같습니다. 이것이 ZBXE의 DB구조에 독립적이라는것이 하위모듈치곤 건방진-_- 부분이기도 하고 다중 DB지원과도 충돌이 있을것 같고...;;;;;)


4. 해결의 기초

-> 첫번째 해결책은 위키모듈을 통해 만들어지는 페이지가 고유의 url을 할당받도록 하는 기능을 포기하는 것입니다.
--> 기능을 포기하더라도 다른방식으로 자기조직화를 이끌어낼 수 있을것으로 예측되며 이것에 대한 고민을 진행할 필요가 있습니다.

-> 두번째 해결책은 위키모듈을 통해 페이지를 작성할 시 작성자가 문서의 고유 URL을 생성할 것인지 선택하게 하는 것입니다.
--> 위키모듈을 통해 만들어지는 페이지 중 고유의 URL을 필요로 하는 페이지가 있을 수 있지만, 아닐수도 있습니다. 이 때문에 전체 컨텐츠 구조 상 필요한 페이지에 고유 URL를 할당해 줄 수 있는 형태 또한 대안이 될 수 있을것으로 보입니다.