> 두 가지가 좀 별개의 질문이긴 한데요.

> 중요한건 enum 형입니다.

> 아직 시험해보지는 못했지만, 매뉴얼을 보고, 이곳 게시판을 보니

> create table 할 때 enum 에 들어가는 것들을 다 정해주던데요.

> 정확히는 모르겠지만, 제가 알고 있는 바로는, db 테이블 타입이 변경이 안되는 걸로 알고 있는데요.

> 그렇다면, 나중에 enum 에 들어가는 것을 추가할 수는 없는건가요?

> 제가 구현하려 하는 것이 예를 들자면, 몇몇 정해진 캐릭터 들이 있고, 나중에

> 캐릭터가 추가되면 더 넣으려고 하거든요. 이걸 좀 알아보기 쉽게 하기 위해

> enum 형태를 쓰려고 하는데요. (c 에서 쓰는 enum 이랑 비슷한 거겠죠? 아니라면--; 딴 방법을 알아봐

> 야 하겠네요--;)

> 그리고요...

물론 추가는 불가능하고, 나중에 새로 modify 를 통해서 재정의하는 것은 가능합니다. 그런데 사용하고자 하는 목적에 크게 맞지 않는 것 같습니다. enum 은 추가가 아니라 고정된 자료형에서 사용하는 것이 합당합니다.

> db 에서 트리같은 구조를 어떻게 구현하는 것이 좋을까요?

> 이게 이진트리도 아니고, 카테고리같은 걸 분류하려고 하거든요. 야후같은 곳의 카테고리 분류처럼,

> 하나의 항목에 수많은 가지가 붙을 것 같구요.

> 물론, 높이도 다 다르고, 이런 경우 어떻게 해야 할지 모르겠네요.

> 가능하면, 이미 많이 쓰이는 방법을 쓰려고 하는데, 우선 제가 생각해본 것이 unix/linux 의 디렉토리

> 관리하는 방법을 찾아보려 했는데..

> 마땅한 문서를 찾지 못해서 리눅스 커널 관련 글을 보니... 자세한 설명이 없어서

> 대충 보고 짐작하기에... 디렉토리 파일에는 그 디렉토리 내 파일들의 inode 들을 갖고 있는 것 같아

> 보이는데... (전혀 확실치 않습니다--;)

> 그래서, 구리나마... 이런 식으로 생각을 해봤는데요.

> parent int, // parent 의 uid 를 가리키고요.

> child text, // child 들의 uid 들을 가리키는데요.

> 각 child uid 들을 구별하기 위해 중간중간 구분자를 넣어야 할 텐데요.

> 이런 방법이 과연 안정된 성능을 보장할 수 있을지 전혀 알 수 없구...

> 좀 좋은 방법을 알고자 합니다.

구현방법은 그정도 생각할 수 있지만 그렇게 썩 좋은 방법은 아닌것 같습니다.

차라리 필드수를 늘리는 것이 어떨까 생각중입니다. 사용상의 편의와 퍼포먼스, 그리고 차지하는 공간 사이에서 적당하게 서로 타협을 봐야 하지 않을까요.

> 실제 Linux/Unix 에서 어떤 식으로 디렉토리를 관리하는지... 그런 모델을 따라 트리 구조를 구현하고

> 싶은데요.

> 어떤 식으로 해야 할까요???

> 긴글 읽어주셔서 감사합니다~~~

읔. 이 문제는 e2fs 에 대해서 공부를 해야 할 것 같군요.

기존의 unix의 inode 테이블을 이용하는 것은 유사하지만 구현된 file system 은 e2fs 라고 부른답니다. 이 에 관한 많은 자료가 존재하고 있으니 참조로 하시기 바랍니다.