간단한 로그를 저장하는 테이블을 설계해보자. 1. SEQUENCE
2. TABLE
3. SYNONYM
4. Primary Key
5. GRANT 1년정도 지표처리 작업을 해오면서 느꼈던 나만의 로그 테이블 설계 원칙을 작성해본다. 1. LogDB에는 2차 가공 데이터는 없어야 한다. -> DB에 박혀있는 값을 가공하여 DB에 INSERT 하는 것은 삼가야 한다. -> 추가적인 가공이 필요한 데이터는 Tool 에서 진행하도록 한다. 2. 알아보기 쉽게. 간단하게 작성되어야 한다. 그렇지만 운영상에 필요한 정보는 반드시 존재하여야 한다. -> 개발자가 LogDB를 SELECT 하는 것 만으로도 해당 로그가 어떠한 이유에서 발생한 것인지를 명확하게 알 수 있어야 한다. -> 개발자가 생각하기에 비교적 필요없는 정보라고 할지라도, 운영상에 필요한 정보라면 반드시 남기도록 한다. -> 특히나, 운영상에 필요한 정보가 Tool 에서 자주 요청되는 정보의 성격이라면 타협의 여지 없이 DB에 남겨야한다. 3. 공통 로그 포맷은 죄악이다. -> 개발의 편의성을 위하여 모든 로그에 대해서 공통된 포맷을 사용하는 경우가 왕왕있다. 공통된 로그 포맷으로도 완벽히 제어할 수 있다면 문제는 없지만, 보통 그렇지 않다. 필요한 칼럼이 있으면 억지로 구겨넣지 말고 늘려야 한다. 4. 하나의 칼럼에는 하나의 정보만을 담는다. -> 로그 시스템이 DW 이상급의 크기를 갖추지 않는다는 전제 하에, 하나의 칼럼에는 하나의 정보만을 담는 것이 좋다. -> 개발자가 SELECT 하였을 때 WHERE 절로 바로 검색가능한 로그 포맷이어야 한다. |