SQL 문장의 사용

모 회사에서 납품한 제품의 SQL문장과 스키마를 점검하고 있습니다.
(세상에 대학에서 이런일을 하는줄은 또 몰랐음. 역시 학문은 일종의 권력.)

보니까 스키마는 일반적으로 짜듯이 잘 짜져있었습니다. 물론 중고급 개발자와
초급 개발자가 혼재한 상태에서 개발했다는 것이 드러나긴 하더군요. 예를들어,
가장 간단한 튜닝중 하나인 게시판에서 제목과 내용의 분리라던가하는게
어디는 되어있고 어디는 안되어있고 한더단가. 사실 뭐 스키마도 그냥 SQL로
다 해놓고 리버스 엔지니어링으로 뽑은건지 알게 뭔가여..

SQL문장을 보면서 몇가지 생각이 들어서 씁니다.

  • OLTP와 OLAP의 차이는 알아야한다
  • 질의가 자주 일어나면 WHERE 절의 조건에 대해 INDEX를 생성할 줄 알아야 한다.
  • 기본적으로 SQL문장의 execution plan정도는 볼줄 알아야한다.
  • FULL TABLE SCAN을 하고 있으면 일단 의심해 봐야한다.
  • Response time과 throughput은 공존하기 힘들다는 점을 알아야 한다.
  • 커멘트 수, 답글 수와 같은 내용은 게시물 제목이 들어있는 테이블(즉 마스터)에 미리 저장해두는 지혜를 발휘할 줄 알아야한다.

아마 이 정도만 잘 해 두었어도 제게 SQL문장이 자근자근 밟히는 일은 없었을텐데
하는 아쉬움이 남는군요…

또한 이번에 작업을 하면서, 대학원 석사라는 사람들이 얼마나 하찮은 실무 지식을
갖고 있는지 다시금 깨닫게 되었습니다. 실행 계획 볼줄 아는 사람도 없고,
OLTP와 OLAP의 차이도 모르고, throughput과 response time을 둘 다 높힐 수
있다고 착각하고, 오라클 시작/셧다운 할 줄도 모르고.

아무래도 MySQL이 여러사람 버려놓는 것 같아요. 오픈소스를 비하하려는 의도는
아니고, 물론 저도 알바할 때는 MySQL을 쓰지만, MySQL만으로 끝나는 일만 하다보면
아무래도 좀 더 발전된 내용을 습득하기가 힘들죠…..

공부할거든지 산업체로 나갈거든지간에 좀 stay tuned for the IT industry 할 필요가
있음.. 이 점은 예전에 이화여대에서 김원박사님이 강연하실 때도 하신 말씀이지만요.

Similar Posts:

Post a Comment

Your email is never published nor shared.