프로시저에 관한 나의 생각

필자가 다닌 첫회사는 모든 SQL문을 프로시저화 하는 회사였다. 충분히 납득이 가는 이유였다. 큰 쿼리는 줄수만 1000줄이 넘어가는 경우도 있었기 때문이다. 그러나 프로시저는 그래도 배포에 대한 부담감으로 다가왔다.

배포를 할때마다 변경한 프로시저를 일일이 수정해주는 방식으로 가야했기 때문이다.(게다가 배포 실수 가능성으로 인해 배포 전 백업까지도 해야했다.)

이 과정은 당연히 자동화되어있지 않았고 일일이 사람 손으로 해야했다.

자회사로 오게 된 이유, 쿼리 길이가 그닥 길지도 않았고 프로시저를 만드는 작업이 번거로운 면도 있었기에 쿼리를 소스코드안에 넣는 방식으로 작업을 진행했더니 배포가 훨씬 더 편리해짐을 느낄 수 있었다.

이런 식으로 방법을 바꿔보니 소스코드내 쿼리를 넣는 것에 대한 장점이 확 와닿기 시작했다. 프로시저는 결국 배포를 하게되면 따로 백업을 하더라도 예전 프로시저를 다시 볼 수 있는 방법이 까다롭다. 그러나 형상관리(git)가 되고 있는 소스코드내에 쿼리를 넣게 될 경우 과거와 쿼리가 어떻게 바뀌게 되었는지에 대해 볼 수도 있고 훨씬 편리해졌음을 느꼈다.

그리고 나중에 우리 회사에서는 Spring과 Hibernate를 사용하게 되었다. 처음에는 Hibernate의 한계가 명확하기 때문에, 왜 꼭 이걸 사용해야하나 납득이 가지 않아서 사용하는 이유를 찾아보았다. 가장 납득이 가는 이유는 테이블을 alter할때 수정하기가 용이하다는 말이였다. 솔직히 쿼리를 소스코드에 넣은 후에도 프로그래밍언어에 종속되지 않기때문에 툴의 Refactor기능을 이용할 수 없고 일일이 텍스트 바꾸기를 사용해야 했는데 만약 다른 테이블의 같은 속성이름을 갖게 된다면? 굉장히 까다로워질 수 밖에 없다.

 

프로시저 => 소스 내 쿼리 => ORM(Hibernate, JPA)에 오기까지 정말 다양한 경험을 해보았는데 꼭 어느 하나가 옳다고 할 수는 없다.

 

프로시저

- 형상관리가 되지 않는다

- 쿼리가 1000줄을 넘어간다던가 하면 쿼리를 DB에 전송하는 시간을 고려해 DB에 저장하는 것이 편리할 수 있다.

 

소스 내 쿼리 

- 형상 관리가 가능하다

- 테이블이 수정될 경우 쿼리를 텍스트 변경을 통해 일일이 찾아서 수정해야한다

   ㄴ 만약 다른 테이블 같은 속성명을 가지는 속성을 수정해야 한다면?

 

ORM(Hibernate, JPA)

- 형상 관리가 가능하다

- 테이블 수정하기가 용이하다