#title 화면마다 테이블 1개씩?!
[[TableOfContents]]

이 패턴은 데이터베이스 설계 자체를 모르는 사람들에게서 나오는 패턴이다. 한 화면에 하나의 테이블이 만들어지는 패턴이다. 예를 들어, 다음과 같은 테이블이다. 

==== 스키마 ====
매입입력(등록자, 등록일자, 매입번호, 매입일자, 업체코드, 업체명, 품목, 구분, 매입금액, 지급금액, 지급예정일, 미지급잔액, 계산서여부, 최종수정자, 최종수정일자, 수정내용, 수정종류)

==== 잠재적인 Trade Off ====
화면 이름이 테이블의 이름과 동일하며, 화면에 쓰이는 데이터가 모두 하나의 테이블에 있다. 분명 개발자들은 죽을 고생을 했을 것이며, 엄청난 유지보수 비용이 들었을 것이다. 아주 몹쓸 패턴의 설계이다. 

 1. 등록 및 수정이 사원에 의해서 발생하는 행위라면 등록자, 최종수정자는 관계이다. 만약 등록, 수정에 대한 감사가 목적이라면 사원에 대한 이력관리가 필요하다. 
 2. 공급업체와 품목이 하나의 테이블에 있으므로 이들 데이터가 변경된다면 이제까지 발생한 데이터에 대한 모든 데이터의 갱신이 이루어져야 한다. 
 3. 수정이 여러차례 일어난다면 수정을 제외한 다른 데이터들이 모두 중복되어 처리량이 늘어난다. 
 4. 미지급잔액도 위의 수정에 대한 이슈와 마찬가지가 된다. 
 5. 기타등등

현재는 '매입입력' 테이블 일부만 보았으나 전체적인 디자인 튜닝이 필요한 것으로 보이며, 3정규화 또는 보이스-코드 정규화로 성능 및 무결성을 보장해야 한다. 수정된 데이터 모델은 대략[* 테이블명과 컬럼명만을 보고 설명한 것이며, 명확한 정의는 없기 때문에 '대략'이란 표현을 사용했다. 설계패턴을 이야기하기 위함이므로 따지지 말자] 다음과 같다. 

attachment:design_tuning08.jpg 

어떤 이는 이런 식으로 하면 모든 테이블에 입력을 해야 하지 않냐고 반문할 수 있다. 그러나 사원에 대한 사항은 이미 입력이 되어 있는 사항이고, 공급업체에 대한 사항들도 이미 거의 정해져 있는 사항일 것이다. 매입입력에 대한 실제 입력되는 데이터는 몇가지 되지 않는다. 또한 수정이력은 통합하였다. 필자는 이런 설계 패턴을 '1화면 1테이블 패턴'이라고 부른다.