도무지 믿기지 않아서 확인해보니 Dump~~ MySQL 3.23.5x ~~ 라고 선명하게 찍혀있었다. 역시 3.23의 문제인가? 개발서버(그리고 최종적으로 운영될 서버)의 MySQL 버젼을 4.0.x 대로 마춰달라고 요청해봐야겠다. 현재 쓰고 있는 내 서버는

redbaron@xxx redbaron$ mysql --version
mysql  Ver 14.5 Distrib 4.1.2-alpha, for portbld-freebsd4.9 (i386)

이다.

DB구조를 보니

MySQL적 사고가 느껴지는 구조였다. 나름대로의 정규화는 있었지만, Contents별로 다른 Schema구조를 ㅤㅆㅓㅅ다. 기능추가하거나 할때 조금 번거롭지 않았을까? 약간 심한 말로는 어차피 다 게시판이다. 그러나 Table을 나누는 기준은 정말 참고가 되었다.(가뭄속에 단비같은..)

위의 문제에 이어

Contents 별로 다른 Schema 구조를 쓴것은 순전히 Hit가 높은 Table에 Index를 잘 걸어서 전체 Load를 줄여보자는 의도였고 몇몇 Table에는 Index가 여러개 나머지 몇몇 Contents들에는 index가 2-3개 정도만 걸려있었다. 물론 Index를 적절히 사용한 훌륭한 예지만.. 역시나 이것도 처리해야 될문제가 되어버렸다. 하지만 처음 만드신 분의 심정은 100번 공감이 간다.

해결해보자

일단은…

분리되는 Contents가 아닌 최대한 통합할수 있는 Contents 끼리 묶어서 하나의 큰 Schema를 만들고 거기에 Indexs를 제대로 생성해주는 수 밖에 없다고 본다. 약간의 속도의 희생이 있겠지만 전체적으로 유연한 유지보수를 위해 충분히 희생할 가치가 있다고 생각한다.

나머지…

크게 구조를 손보지 않고 그대로 가져가야 하는 DB들이 있다. 이런 경우에는 Indexs나 Select Query를 약간 손보는 수 밖에 없나? 아직 전체 Table의 수가 50개도 되지 않는 상황이므로 정규화의 여유는 충분히 있다. 사실 Table 100개를 1개의 DB가 수용가능한 Max로 늘 스스로를 세뇌하고 살고 있다. ^^

갈무리

기존의 개발자의 어떤 형편과 처지를 눈치챌 수 있는 DB였고, 그래서 좀 씁슬했다. 이야기가 딴길로 세는것 같지만, 약간의 여유와 제대로된 프로세스(?)와 환경이 였으면 나오지 않았을 수도 있는 DB구조였고 그 개발자분이 처해잇는 형편에서 할 수 있는 가장 합리적인 DB구조 였다. 이 DB를 만드신 분의 성실함에 박수를 보내고 싶다.