개발일기장
이동 기록을 남길 때 생각을 해봤는데 본문
쓰던 컴터가 당장 없어서 TABLE을 확인할 수가 없긴한데 기억 더듬어보면
RECORD table
| RECORD_ID(PK) | USER_ID(FK) | ... |
TRIP_ID는 seq로 했는데USER_ID랑은 독립적..
LINE table (RECORD와 1:N)
| RECORD_ID(PK/FK) | SEQ(PK) | from 위도 | from 경도 | to 위도 | to 경도 |
이거는 point끼리 연결하기 위해서 이렇게 설정을 했음
AREA table (LINE과 N:N)
| 위도(PK) | 경도(PK) |
이 데이블은 특정 사각형 구역에서 우하단의 좌표를 가지고 있다는 설정임
그곳을 지나가는 point에 대해서 counting을 하기 위해서 이렇게 했었엇음 -> 그것을 위한 table이 따로 있음
대충 이렇게 구성을 하고 JOIN을 했던것 같다.
근대 일하면서 오늘 갑자기 생각난것인데
굳이 from~to의 위도 경도를 하나에 저장해야 하는것인가에 대한 생각이 들긴했음
double type의 값을 4개씩이나 하나에 저장하는 부분도 그렇고
해당 LINE record의 to값이 다음 seq의 from값과 겹친다는 느낌도 맘에 안들었음
LINE table에 대해서 구성을 해보면 다음과 같다.
| from_node(PK) | to_node(FK) | seq |
이렇게 하고 조회를 할 때에는 connect by 구문을 사용한다.
RECORD table에는 해당 산책을 시작할 때의 from_node값을 가지는 column을 추가하면 될것 같다.
그리고 NODE_VALUE table을 새로 만들어서 거기에 위도, 경도값을 저장하는 방법이 있는것 같다.
그러면 NODE_VALUE table 만으로도 AREA table과 N:N join을 할 때 from/to column 때문에 더러운 코드를 깔끔하게 만들 수 있을것 같다는 생각을 했음
근대 단순히 table이 깔끔한것을 넘어서 성능이 프로그램이 요구하는 트랜젝션에 대해서 성능이 잘 나와야함
고려해 봐야할 점
1. 해당 유저가 자신의 모든 기록을 확인할 때
2. 특정한 AREA를 지나는 점에 대한 counting을 할 때
1의 경우에는
(1) USER--- (1 : N)
(2) --- RECORD --- (1 : 1) (시작하는 from_node만 저장해도 되니깐)
(3) --- LINE --- (1 : 1 connect by ) --- LINE [각각의 LINE은 NODE_VALUE table과 1:1 join)
이렇게 JOIN을 쭉쭉 연결해나가야한다. (1)의 경우에는 안해도됨 RECORD에 이미 USER_ID가 FK로 사용됨
(2)의 경우에도 1:1 join이고 LINE의 각각의 from_node는 PK이기 때문에 JOIN이 빠르다
(3)의 경우에도 connect by가 1:1구성 + unique index(PK)로 되어있기 때문에 괜찮을 것이다.
결국은 from_node의 값을 어떻게 구성하느냐가 관건인것 같다.
단순히 넘버링하는것은 뒤에 seq가 있기 떄문에 상관이 없고,
random한 숫자로 구성하는것은 나중에 data block이 분산되게 되면 성능을 저하시키는 요인이 될 것이다.
그래서 생각해본게 해당 지역 code + user # + random #이렇게 하고 indexing을 하면 좋지 않을까..
여기서 막혔다.
단순히 책에 있는 공부보다 이미 적용되어서 돌아가고 있는 서비스에서 배울점이 많은것 같다........