best practice of designing DAO

best practice of designing DAO

지금까지의 경험을 정리하는 것입니다만, DAO의 구축에 대해 한 번 알고 있는 모든 것을 동원해 "어떻게 하는 것이 좋은 지"에대해 한 번 생각해 보고자 합니다.
Database를 이용하는 우선 설계의 방식에는 여러가지가 존재할 수 있습니다. 각각 모두, 요구되는 '기록과 열람'이라는 내용은 만족합니다. 그러나 어떤 것이 왜 좋은지 알 지 못한다면 곤란합니다.

우선은 기본적인 Data의 설계는 각 프로젝트별로 맡기고, 여기에서는 공통적으로 다루어야 할 issue에 대해서만 촛점을 둡니다만, DB의 모델링에 대해서는 다양한 시스템에 대한 설계의 경험을 쌓아야 합니다.

각 프로젝트별로 필요한 필드의 추출, 추출방식은 도메인 모델을 기준으로 하던지, use case를 기준으로 해도 문제가 되지 않습니다. 또한 generalizing과 degeneralizing도 어느쪽에 비중을 더 크게 두더라도 틀린 것은 아닙니다. 오히려 어느쪽에 비중을 더 두었는 지를 보고, 어떤 기능이 들어가는지 기획을 짐작할 수 있습니다.
리소스에 여유가 있다면, Fetch용 Database와 DML용 Database를 따로 두는 것도 가능합니다. 이런 경우의 Database의 설계는 일반적인 경우와 많이 다른데, 일반적인 경우만 다루어본 사람이 이러한 구조를 알지 못한 채, 이런 ERD를 만나면, "DB를 잘 알지 못하는 사람이 작성했나보군"하고 생각할 지도 모릅니다.

공통적으로 다루어야할 Database의 설계에 대한 Issue로 여기고 있는 것은 다음과 같습니다. 안전한 Data의 취급이 무시되어야 하는 시스템은 없을 것입니다.
다음에 적는 것들은 없어도 기록의 출입을 구성하기에는 문제가 없습니다만, 고려해 보아야 할 내용들입니다.

1) Optimistic Lock
2) Trigger를 이용한 Update Delete시의 Transaction Table에의 기록.
3) Procedure를 이용한 DML(plus DML query의 실행제한)

Optimistic Lock은 시스템의 구성에 따라 꼭 필요하기도 하고, 없어도 상관없는 경우가 있습니다. Transaction의 기Term이 긴 시스템이라면 반드시 필요합니다. 구현은 프로시저를 사용하지 않고 코드에서 구현한다면, 상당한 작업량이 될 수 있습니다. 만일 프로시저를 사용할 수 없다라면, OR-Map의 도입도 고려해 보는 것도 좋다라고 생각합니다.

Trigger를 이용한 Transaction을 Table에 기록하는 것은 고객의 동작을 기록해 놓는 것으로 , 안전성의 의미가 큽니다.

Procedure를 이용한 DML은 parameter check도 코드에서 하는 것이 아니라 procedure에서 하겠다는 얘기입니다. Data기록의 로직은 Database의 Procedure에 두겠다는 것은 한 가지 언어 이외에도 복수의 언어로 구성된 시스템에서 동일한 기록의 동작을 보장합니다.

이것은 DB에 매우 큰 로드를 걸지 않는 한, 매우 바람직합니다라고 생각됩니다만, 실제로 많이 사용되는 경우는 보기 어려웠습니다. 특히 Procedure를 사용하지 않고, Application서버가 여러대로 분산되어 있을 경우 부하를 DB보다는 Application서버에 두려 하는 경우, 또 OR-Mapper를 더 선호해서 이를 통한 DML 작업을 하는 경우가 이유로 많이 제시되곤 했습니다.
그러나 잘 생각해보면, Hibernate등의 OR-Mapper를 사용한다고 하더라도 Select에 대한 작업은 Cache Provider등을 사용해 이득을 볼 수 있지만, Insert Update Delete에 대한 작업이 그리 많이 이득을 볼 수 있는 시스템이라고 확실히 얘기할 수 있는 시스템은 많지 않은 것 같습니다.
Hibernate등을 선호하는 케이스라면, 시스템이 허용하는 한, 사용해도 좋다고 생각합니다.
이런 경우라면 insert update delete 명령어를 금지하면 안되겠지만, DBA계정이 아닌, Application이 사용하는 계정이라면 금지를 생각해보는 것도 가능할 지 모릅니다.(실제 그렇게 운영해 본 적은 없습니다만...)

아아.. 오늘은 이만 해야겠습니다.
이 문서는 완전한 것이 아니므로 추가될 것입니다.