db설계에 대해 한마디 하려고 합니다.

책에 나온대로 정규화니 뭐니 하면서 공식대로 만들어봤지만

최종사용자의 다양한 형태의 보고서를 db에서 추출하고자

할때 온갓 조인과 서브쿼리들이 난무하게 됩니다. 대부분

하나의 쿼리 길이도 엄청나지요.

그에 대한 방안으로 뷰와 저장프로시져같은것을 사용하게 되는것이겠지만.

뷰와 저장프로시져를 지원하지 않는 db도 있습니다.

조인과 서브쿼리 쓰는거 당연할수도 있죠.. 정규화 작업을 거쳤으니..

물론 관계형 db에서 정규화는 당연한 절차이고 왜 해야하는지를

알고는 있지만 책의 공식만으로 제작된 db는 실무에선 안통할때도 있다는

겁니다. 아니 솔직히 거의 안통한다고 봅니다.

어떤 회사에서 만들어 놓은 db를 봤는데 처음엔 속으로 욕을 많이 했습니다.

관계도 명확하지 않고 중복되는 데이터가 발생될 여지가 여기저기에서

발견되며 무결성따위는 고려조차 하지 않은듯한.. 책에 나온 공식대로

따지면 빵점짜리 설계지요. 하지만 신기하게도 그런 db를 사용하는

응용프로그램이 아주 잘 돌아갑니다. 아마도 응용프로그램 영역에서

db가 해야할 역할들을 대신하고 있는 듯 한데 수년동안 사용되어오면서

안정성은 입증된 상용프로그램이니 할 말없게 만들지요.

다른 여러 상용 프로그램들을 서베이해봤지만 역시 책에 나온 공식대로 하여

100점짜리 설계를 본 적이 없었습니다. 그 사람들이 저보다 못해서

100점짜리 설계를 하지 못한것이 아닐껍니다. 잘나도 한참 잘난 사람들이라

십수년간 그 방면에서 나름대로 날고 긴 사람들일텐데..

결국 느낀것은 이론은 이론일뿐이다. 라는 겁니다.

그리고 실무에선 프린트되어 나온 결과가 중요하지 그 내부는

쳐다도 보지 않는다는거지요. 조인과 서브쿼리로 멋지게 쿼리문을

작성해봐야 속도만 느려질뿐 결과는 동일합니다.

이렇게 되면 최종사용자는 오히려 빵점짜리 설계에 점수를 더 주겠지요.

흠.. 기존에 설계한 db를 다시 뒤엎고 있다가 갑자기 화가나서

한마디 적어봤습니다.