윤개발

Gathering-bot 서비스를 개발하면서 성능에서 가장 크게 고민했던 부분에 대한 포스팅입니다. 1. 초기 설계 개발 전 Gathering-bot 서비스 데이터베이스 설계는 다음과 같습니다. 다른 테이블(사람, 배치등)과 일부 컬럼(생성한 사람, 응답시간등)은 주제와 연관이 없어 표기하지 않았습니다 시트는 1개 이상의 취합 항목을 가지고 있습니다. 취합 항목은 시트_id 를 FK로 가진다. 시트는 1개 이상의 응답을 가지고 있습니다. 응답은 시트_id 를 FK로 가진다. 응답은 1개 이상의 응답 항목을 가지고 있으며 시트의 취합항목에 대한 응답입니다. 응답 항목은 응답_id를 FK로 가지며 취합항목_id를 FK로 가진다. 2. 성능 이슈 고민 초기 데이터베이스 설계와 함께 JPA의 지연로딩을 사용하여..

🖐️ 프로젝트 개요 사내에서는 많은 취합 업무가 발생하며 주로 엑셀을 통해 작성하고 메일로 전달되어 통합된다. 메일로 이루어지기 때문에 취합담당자는 수많은 엑셀을 받아서 통합하는 과정이 필요하다. 우리 회사는 폐쇄망이므로 외부 인터넷이 불가능하다 즉 구글 설문조사, 공유문서 사용이 불가능하다 엑셀로 처리하는 취합업무를 빠르게 처리해보고자 프로젝트를 시작하게되었다. 🔎 조사 사내망에서 구글 설문조사, 구글 공유문서를 사용할 수 없음. 미응답자에게 다시 회신해달라는 리마인드 메일을 보내야하는 불편함, 제출 안한 사람의 이메일을 일일히 입력해줘야하는 귀찮음 응답하는 인원은 일을 미뤘다가 응답을 잊을 수도 있음. 수정 요청하는 경우에는 취합을 다시 반복해야함 🔥 프로젝트 내용 취합 담당자 로그인을 하고 시트를 ..