데이터베이스 결과값 어디서 만드는 게 좋은가

- 결론은 기본적으로 가장 필요한 만큼의 데이터를 불러와 로직에서 결과값을 만드는 것이 기본이다. 성능 문제가 중요한 부분만 복잡한 SQL로 처리해서 성능을 향상시키는 것이 바람직하다.

- Domain Layer의 기본은 Service 레이어가 필요로 하는 형태의 데이터를 제공하는 것이다. 즉 Domain Layer, Domain Logic에서 수행 할 가장 근본적인 과제이다. 

- Service 레이어는 어떤 형식으로 데이터가 만들어졌는지에 대한 정보를 가질 필요가 없다.

- MyBatis는 Domain Layer의 정보를 Mapper를 통해 SQL로 처리하는 독특한 형태를 가지고 있어 가장 활용성이 높다. 솔직히 로직을 재사용할 일은 거의 없기 때문에 뭐든 상관 없다.

 

 

---------------------------------------------------------------------------------------

 

 * 이 주제는 누구나 한 번 즈음은 생각해 보는 부분이다. 

 

- 대부분의 관공소에서 운영하는 오래된 시스템은 기본적으로 오라클 데이터베이스에 stored procedure과 store fucntion으로 도배가 되어 있다. 

- 기본적으로 전산직 공무원은 데이터베이스를 다루는데 더 익숙하기 때문에 멍청하게도 데이터베이스에 모든 것을 해결하는 것을 선호한다. 그래서 재개발 시에도 업체에게 데이터베이스 모든 것을 처리하는 것에 관대하다.

- 물론, 이렇게 작업할 경우 마이그레이션이 어렵다는 문제가 있지만, 솔직히 마이그레이션을 할 확율이 제로인데 이건 큰 문제가 되지 않는다.

- 결국 데이터베이스 서버는 비싼 오라클 라이센스와 22%에 달하는 유지보수에도 수억을 들여서 만든 서버 리소스는 사용율 90%가 넘나들지만 WAS 서버의 CPU 사용율은 1% 남짓한 것이 대부분이다.

- 문제는 데이터베이스 로직인데 작성할 때는 편할지 몰라도 수정할 때는 답이 없다. 찾기도 쉽지 않고 구조화가 잘되어 있지 않기 때문에 수정을 하면 어떤 문제가 생길지 예상하기가 쉽지가 않다.

- 가장 큰 문제는 여러 데이터베이스 계정으로 DBLink를 사용하면 Locking 문제가 발생하는데 이건 microservice가 아닌 한 서비스 전체를 정지시켜버린다. 물론 DB암호화 모듈같이 데이터베이스와 연관련 부분이 문제가 생겨도 마찬가지이다.

 

- 아래의 링크는 마틴 파울러가 약 20년 전에 작성한 글인데 결국은 다 같은 고민으로 귀결된다. 내용은 간략하고 소스는 루비로 작성되어 간결해서 쉽게 이해 된다.

 

 

Domain Logic and SQL