여러개 필드를 미리 만들어 놓기 보다는, 사용자가 항목을 만들면, 그 때 마다 해당 항목의 Table이 하나씩 만들어지도록 처리하는 것이 훨씬 좋은 방법일거 같네요. 단, Table의 구조는 적절하게 범용화시켜서, 해당하는 모든 Table이 똑같이 만들어야 하겠죠.

이럴 경우에, 어떤 어떤 항목들이 만들어졌고 각각의 테이블명이 어떻게 된다는 항목을 따로 Table하나로 묶어서 관리하는게 통상적일겁니다.

근데, 예를 들어 사용자가 계정과목을 결정하는 경우에는 이렇게 처리하는게 바람직하지만, 단지 그 계정과목에 해당하는 입력항목들에 대해서라면, 대개 그런 처리는 바람직하지 않겠구요.

(예를 들어 '현금수입'이라는 계정항목이 있다손 치면, 그 아래에 '**거래처', '##기업' 이런 입력항목들이 들어올 수 있겠죠. 전자의 경우가 다변화되는 거야 각각 Table로 지정해주는게 효율적이겠지만, 후자의 경우는 각각 Table로 지정하기 보다는, 차라리 그 항목들의 List가 저장되는 detail table을 하나 만들어서 관리하는게 낫겠죠.)

그리고 각 Table에는, 일관된 계산 함수들이 어떤 필드를 어떻게 이용하면 되는지에 대한 적용 계획이 있어야 할 것이고.. 처음에 Table 구조만 잘 설계하믄, 똑같은 구조의 Table을 계속 써도 됩니다.

만약, 규모가 그리 크지 않은 회계프로그램에서라면, 그 테이블을 단 한개로 하고, 이것이 어떤 항목의 처리인지에 대한 flag field를 하나 더 두면 되겠네요. 그리고 그 flag field에 들어온 값이 각각 어떤 항목을 의미하는지에 대한 detail table을 두면 되구..

처리방법은, 사정에 따라 각양각색일겁니다.
중요한 것은, 테이블을 read하는 것과 write하는 시간, create하는 시간 등을 감안하여, 구축하는 시스템의 사정에 가장 적절하게, 시간이 최대한 덜 걸릴 수 있도록 예측하고, 그 예측을 뒷받침하기 위해 몇 번 정도 모의 실험 해보는 게 아닐까 싶어요. (규모가 작게 한번 짜보고, 실제DB를 돌려보는거죠. 100% 맞아떨어지는 예측은 아니지만, 이런 실험은 '대략'의 퍼포먼스를 측정하는데 확실히 도움이 되고, 그런 '대략'을 알고 모르고는 큰 차이가 나니까요.)

쓸데없는 헛소리만 한거 아닌가 싶네요. 그럼.. ^^;

프로그램 경험이 거의 전무하다보니 무슨 말씀인지 잘 모르겠지만, 일단 말씀을 토대로 한 번 찾아봐야겠습니다.^^

감사합니다.