몇주전부터 사내 DW 프로젝트에 투입되었습니다. (한창 진행중입니다..)
일단 한동안 자바만 보느라고 DB(쿼리)에 관심을 끊은지가 좀 되어서
쿼리에 대한 감도 없었고, 투입전 사전 분석에 참여하지 못 했기 때문에 프로젝트에 대해서 아는 것도 거의 없었습니다.
그 상태로 투입이 되어서 곧 바로 개발환경을 셋팅해서 잡아주고
개발을 시작하려고 했습니다.
dwr,그리드 등등을 사용하기로 했지만, 필요한 곳에서만 최소한으로 사용하는 것으로 결정하고
view는 프리마커와 사이트매쉬를 사용하기로 했습니다.
일단, 장표 테이블이 나와야 하는 화면들이 많았는데
그 테이블의 꽤나 복잡했고
depth 별로 소계, 합계 그리고 그 원래 테이블의 pivot등
여러가지 모양의 테이블들이 존재하더군요...;;
일단 간단하게는 위와 같은 기본적인 모양의 장표 테이블부터..
이런식의 테이블.. 그리고
이런 장표들...
각각의 지표는 10개정도가 되는 것도 있었고 표의 row와 column도 길었지만
각각의 표를 만들기 위해 쿼리로 저런 표의 모양대로 뽑아내는 것이 쉽지 않아보였습니다.
게다가 DB가 mysql로 선택된 상태여서 오라클만 주로 사용하던 저희들에게는 조금 생소한 부분도 있었지요..
계산되는 부분도 단순히 sum 뿐만이 아니라 소계에서의 평균, 합계에서의 평균, %를 구하는 부분도 있었고
해서 이거를 쿼리로 어떻게 해야하는 것이 맞나.. 그렇게 가져온다고 한들.. 위 카테고리에 대해서는 rowspan등을
넣어줘야 표가 제대로 만들어 질텐데..하는 생각도 들었습니다.
그리고 이걸 쿼리로 작성해서 풀려다보니 쿼리가 쓸데없이 지저분해지고
특히 pivot (일명 row to col)은 쿼리의 길이가 많이 길어지고 보기도 안 좋았습니다.
그렇다고 view단에서 나누고 더해서 뭐 할 때는 rowspan하고 어떨때는 뭐 뿌려주고
이런식으로 작업을 해 놓는다면
나중에 그 페이지에 컬럼하나 추가하러 페이지를 열어본 어느 운영 개발자는
식겁하겠죠.
도대체 왜 여기서 나누기를 했고 왜 더하고 있고 왜 왜 왜 왜 view단에 if가 이렇게 많은거야 ㅠㅠ 하고요..
그래서 고민하다가 문득 생각나는 것이 있었습니다.
'Table를 클래스화 해볼까??'
즉, 자기의 메뉴나 자기가 어떻게 그려질지 등은 Table 그 자체가 알고 있는 것이고
get소계 하면 해당 row의 소계를
get합계 하면 해당 row의 합계를
아무튼 이런식으로 하고, getLeftMenu 하면 테이블이 자기가 가지고 있는 resultSet으로 메뉴를 만들어 보내주고..
그러면 view에서는 단순히 table.getLeftMenu() 이런식으로 메뉴 불러지는 부분을 대신 할 수 있지 않을까 싶었습니다.
그리고 소계나 합계등도 raw 데이터만 가지고 와서 자바에서 전부 계산해서 가지고 있어보자..
하는 식의 생각이 정말 그냥 스치고 지나갔습니다 -_-;
구체적인 구현방안이 떠오르지는 않았지만 그냥 불현듯 스치는 듯한 느낌? -_-
그래서 일단 풍대리님께 가서 잠시 대화를 나누고 이런 방향으로 가도 괜찮다는 확인을 하였습니다.
풍대리님의 얘기와 조언을 들으면서
1. "데이터를 내가 원하는 모양대로 만들어내는 것이 중요하겠구나.." 라는 생각과
2. "데이터에 대해서 너무 어렵게 생각하지말자.." 라는 생각과 방향을 갖게 되었습니다.
그리고 이제 고민을 해보았습니다.
어떻게 해야 생각했던대로 개발 할 수 있을까..? 어떻게 해야 그래도 하나의 모듈로서 다른 장표에서도 쉽게 적용해 사용 할
수 있을까.. 하구요..
1. 일단 방향을 잡은 것은 쿼리는 최대한 쉽게 작성해도 장표를 만들 수 있도록하자.. 그게 생산성이 높을 것 같다..
2. Domain 객체에서 값을 가지고 있고 그 값으로 계산을 할 수 있는 내용이라면 쿼리에서 계산하지 말고
Domain 객체 에서 자기 것을 계산해서 return해주도록 하자..( 이익%를 계산하는 방법은 Domain객체 자기가 알고
있으면 된다.)
3. 소계와 합계도 하나의 Domain객체로서 값을 가지고 있도록 만들자.. (쿼리에서 내지 말자.)
어차피 소계나 합계도 각각의 항목에 대한 값을 가지고 있는 하나의 Domain 객체일 뿐이다.
4. 표의 모양이 쿼리 결과에서 Row로 나온 항목들이 표의 컬럼으로 올라가야 한다면 쿼리에서 decode등을 사용해서 돌리도록 하지말고 쿼리 결과에서는 기본적인 Raw 데이터만 가져오고, 이것을 Pivot 된 표에서 뿌리기 편하도록 데이터를 다시 만들어내자.
라는 정도의 생각을 하였습니다.
시간은 없고.. 뭔가는 해야겠고... 마음은 급하고.. 심란했습니다.
그렇다고 제가 이런걸 한번 만들어본적이 있는 것도 아니고
이렇게 하는게 맞는지도 몰랐구요.. 다만, view에서 loop를 돌려가면서 if else로 장표를 그리는 것이 싫었고
쿼리를 짜느라고 시간을 보내는 것도 싫었기 때문에 한번 부딫혀보자라는 마음으로 달려들어 보았습니다.
일단 한동안 자바만 보느라고 DB(쿼리)에 관심을 끊은지가 좀 되어서
쿼리에 대한 감도 없었고, 투입전 사전 분석에 참여하지 못 했기 때문에 프로젝트에 대해서 아는 것도 거의 없었습니다.
그 상태로 투입이 되어서 곧 바로 개발환경을 셋팅해서 잡아주고
개발을 시작하려고 했습니다.
dwr,그리드 등등을 사용하기로 했지만, 필요한 곳에서만 최소한으로 사용하는 것으로 결정하고
view는 프리마커와 사이트매쉬를 사용하기로 했습니다.
일단, 장표 테이블이 나와야 하는 화면들이 많았는데
그 테이블의 꽤나 복잡했고
depth 별로 소계, 합계 그리고 그 원래 테이블의 pivot등
여러가지 모양의 테이블들이 존재하더군요...;;
| 주문액 | 주문양 | 매장방문자수 | ... | ||
| 합계 | XXXX원 | ||||
| 의류 | 소계 | XXXX원 | |||
| 점퍼 | XXXX원 | ||||
| 바지 | XXXX원 | ||||
| 셔츠 | XXXX원 | ||||
| 가전 | 소계 | XXXX원 | |||
| 냉장고 | XXXX원 | ||||
| TV | XXXX원 | ||||
| ... | ... |
일단 간단하게는 위와 같은 기본적인 모양의 장표 테이블부터..
| 금일 | 전일 | 전전일 | .... | 합계 | |||
| 의류 | 소계 | 주문액 | |||||
| 주문양 | |||||||
| 매장방문자수 | |||||||
| 점퍼 | 주문액 | ||||||
| 주문양 | |||||||
| 매장방문자수 | |||||||
| 바지 | 주문액 | ||||||
| 주문양 | |||||||
| 매장방문자수 | |||||||
| 셔츠 | 주문액 | ||||||
| 주문양 | |||||||
| 매장방문자수 | |||||||
| 가전 | 소계 | 주문액 | |||||
| 주문양 | |||||||
| 매장방문자수 | |||||||
| 냉장고 | 주문액 | ||||||
| 주문양 | |||||||
| 매장방문자수 | |||||||
| ... | ... | ... |
| 금일 | 전일 | ... 합계 | |||||
| 주문액 | 주문양 | 방문자수 | 주문액 | 주문양 | ... 합계 | ||
| 합계 | |||||||
| 의류 | 소계 | ||||||
| 점퍼 | |||||||
| 바지 | |||||||
| 셔츠 | |||||||
| 가전 | 소계 | ||||||
| 냉장고 | |||||||
| ... | ... | ... |
이런 장표들...
각각의 지표는 10개정도가 되는 것도 있었고 표의 row와 column도 길었지만
각각의 표를 만들기 위해 쿼리로 저런 표의 모양대로 뽑아내는 것이 쉽지 않아보였습니다.
게다가 DB가 mysql로 선택된 상태여서 오라클만 주로 사용하던 저희들에게는 조금 생소한 부분도 있었지요..
계산되는 부분도 단순히 sum 뿐만이 아니라 소계에서의 평균, 합계에서의 평균, %를 구하는 부분도 있었고
해서 이거를 쿼리로 어떻게 해야하는 것이 맞나.. 그렇게 가져온다고 한들.. 위 카테고리에 대해서는 rowspan등을
넣어줘야 표가 제대로 만들어 질텐데..하는 생각도 들었습니다.
그리고 이걸 쿼리로 작성해서 풀려다보니 쿼리가 쓸데없이 지저분해지고
특히 pivot (일명 row to col)은 쿼리의 길이가 많이 길어지고 보기도 안 좋았습니다.
그렇다고 view단에서 나누고 더해서 뭐 할 때는 rowspan하고 어떨때는 뭐 뿌려주고
이런식으로 작업을 해 놓는다면
나중에 그 페이지에 컬럼하나 추가하러 페이지를 열어본 어느 운영 개발자는
식겁하겠죠.
도대체 왜 여기서 나누기를 했고 왜 더하고 있고 왜 왜 왜 왜 view단에 if가 이렇게 많은거야 ㅠㅠ 하고요..
그래서 고민하다가 문득 생각나는 것이 있었습니다.
'Table를 클래스화 해볼까??'
즉, 자기의 메뉴나 자기가 어떻게 그려질지 등은 Table 그 자체가 알고 있는 것이고
get소계 하면 해당 row의 소계를
get합계 하면 해당 row의 합계를
아무튼 이런식으로 하고, getLeftMenu 하면 테이블이 자기가 가지고 있는 resultSet으로 메뉴를 만들어 보내주고..
그러면 view에서는 단순히 table.getLeftMenu() 이런식으로 메뉴 불러지는 부분을 대신 할 수 있지 않을까 싶었습니다.
그리고 소계나 합계등도 raw 데이터만 가지고 와서 자바에서 전부 계산해서 가지고 있어보자..
하는 식의 생각이 정말 그냥 스치고 지나갔습니다 -_-;
구체적인 구현방안이 떠오르지는 않았지만 그냥 불현듯 스치는 듯한 느낌? -_-
그래서 일단 풍대리님께 가서 잠시 대화를 나누고 이런 방향으로 가도 괜찮다는 확인을 하였습니다.
풍대리님의 얘기와 조언을 들으면서
1. "데이터를 내가 원하는 모양대로 만들어내는 것이 중요하겠구나.." 라는 생각과
2. "데이터에 대해서 너무 어렵게 생각하지말자.." 라는 생각과 방향을 갖게 되었습니다.
그리고 이제 고민을 해보았습니다.
어떻게 해야 생각했던대로 개발 할 수 있을까..? 어떻게 해야 그래도 하나의 모듈로서 다른 장표에서도 쉽게 적용해 사용 할
수 있을까.. 하구요..
1. 일단 방향을 잡은 것은 쿼리는 최대한 쉽게 작성해도 장표를 만들 수 있도록하자.. 그게 생산성이 높을 것 같다..
2. Domain 객체에서 값을 가지고 있고 그 값으로 계산을 할 수 있는 내용이라면 쿼리에서 계산하지 말고
Domain 객체 에서 자기 것을 계산해서 return해주도록 하자..( 이익%를 계산하는 방법은 Domain객체 자기가 알고
있으면 된다.)
3. 소계와 합계도 하나의 Domain객체로서 값을 가지고 있도록 만들자.. (쿼리에서 내지 말자.)
어차피 소계나 합계도 각각의 항목에 대한 값을 가지고 있는 하나의 Domain 객체일 뿐이다.
4. 표의 모양이 쿼리 결과에서 Row로 나온 항목들이 표의 컬럼으로 올라가야 한다면 쿼리에서 decode등을 사용해서 돌리도록 하지말고 쿼리 결과에서는 기본적인 Raw 데이터만 가져오고, 이것을 Pivot 된 표에서 뿌리기 편하도록 데이터를 다시 만들어내자.
라는 정도의 생각을 하였습니다.
시간은 없고.. 뭔가는 해야겠고... 마음은 급하고.. 심란했습니다.
그렇다고 제가 이런걸 한번 만들어본적이 있는 것도 아니고
이렇게 하는게 맞는지도 몰랐구요.. 다만, view에서 loop를 돌려가면서 if else로 장표를 그리는 것이 싫었고
쿼리를 짜느라고 시간을 보내는 것도 싫었기 때문에 한번 부딫혀보자라는 마음으로 달려들어 보았습니다.
