■ Back-End/- PostgreSQL
-
데이터 조회 속도 개선 > part.1 DB■ Back-End/- PostgreSQL 2019. 5. 24. 09:00
연락처 서비스 개발시 많은 데이터를 조회해서 화면에 뿌려줘야 하는 경우가 있었는데, 페이징 처리를 하지 않고 한 번에 다 보여줘야 했다. 우선 DB에서 데이터를 조회할 때 함께 Join 걸어야 하는 테이블의 수가 많아서, 데이터가 많을 경우 시간이 오래 걸렸다. 그리고 화면에서는 보여줘야할 값들이 많아서, 스크롤을 내릴 때마다 버벅거림이 심했다. 이 두 가지 이슈를 해결하기 위해 쿼리 튜닝과 Indexed DB를 이용한 캐싱 처리를 진행했다. 1. 쿼리 튜닝 DB 구조 테이블 명 구조 기본정보 address_service_no(PK), user_no(PK), user_name, .... 전화번호 정보 address_service_no(PK/FK), phone_no(PK), phone_type, phone..
-
Table 생성시 column의 위치에 대하여■ Back-End/- PostgreSQL 2019. 2. 4. 17:10
[2019.01.28~2019.02.01 업무관련] 얼마 전 신규 서비스 API 개발을 맡게 되었는데 이번에 처음으로 DB 설계 기회를 얻게 되었다.다행히 API가 CRUD 기능 위주여서 DB 설계가 엄청 어렵진 않았다. 몇 시간동안 기획서를 뒤적이며 열심히 DB 설계를 했고, 팀장님께 보여드렸는데팀장님이 컬럼 위치에 대해 물어보셨다. 문제의 테이블!!! 이용기록 테이블은 직원들이 조회한 컨텐츠에 대한 이용 기록을 저장하는 테이블이다.로그 적재가 목적이기 때문에 history_no를 시퀀스로 추가했다.이 테이블은 나중에 '내가 이용한 컨텐츠' 에서 사용되기도 하고, 관리자 페이지에서 통계를 낼때 사용할 예정이다. 테이블을 사용하는 목적에 따라, 컬럼의 위치도 고려해야한다고 history_no와 conte..