지인으로부터 사이트 리뉴얼에 대한 질문들을 받아 이에 대한 답변을 보내드렸는데요. 저급한 수준의 답변일지도 모르나 다른분들께도 도움이 될까하여 공유해봅니다.
1. 왜 페이지를 넘겼다가 다시 빽해서 보면 리스트가 조금씩 틀리게 보이는데 왜 이렇지?
어떤 조건으로 조회를 하셨는지 모르겠지만, 제 환경에선 그런 현상이 없는 점과 조회 요청을 전송하는 방식이 post인 점, 그리고 페이징 번호는 get 방식으로 전송되는 링크로 구성되어 있는점으로 미루어 보면, 개발자가 뒤로가기로 post 방식으로 요청한 페이지를 다시 불러올 때의 상황에 대한 고려없이 코딩을 하였거나, POST와 GET 방식에 따라 파라메타 처리 방식이 다른점이 몇 생길수도 있는데 그부분에 대한 고려없이 코드를 작성했거나, 마지막으로, DB로 요청하는 쿼리의 페이징 처리 부분에 오류가 있을수도 있겠군요.
2. 데이터량이 많아서 검색해서 보여 줄 때 다르게 보이는건가?
데이타량과는 무관한 것으로 보이며, SQL 쿼리 또는 페이징 처리에 심각한 오류가 있을 것 같다고 추청됩니다.
3. 그리고, 총 2346 페이지에 각 페이지 20개씩 이름이 등록되어 있는데, 이 대로 계산하면 계산해 보면 46,920명인데, 화면에는 이렇게 나오는데 나머지 인원은 어디에 있을 것 같아?
제가 조회한 시점에는 전체 2,348 페이지, 70,431명으로 조회되었습니다. 물론, 이 결과도 오류 투성인데요. 전체 인원수가 70,431명이고 한 페이지에 20명씩 나온다고 한다면, 전체페이지의 수는 3,522가 될것이고 맨 마지막 페이지엔 11명이 리스팅되겠지요. 선생님의 조회 결과를 보면 전체 페이지수가 2,346인데요. 이 경우라면 전체 인원수를 정확히 46,920명이라고 단정할수 없고, 46,901~46,920명이라고 보아야겠지요. 그리고 전체 페이지 수에 따라 추정되는 총인원수 범위에서 한참이나 벗어난 70,376명이란 결과가 화면에 나온건 아마도, 리스팅될 사람들을 조회하는 쿼리의 where 절과 sum()을 조회하는 쿼리의 where 절의 불일치로 기인한 것으로 추청됩니다. 한마디로 참 허접스럽게 코딩을 했다는 결론 말곤 ...
4. 어쩌면 이 일을 받을지도 모르는데, 기존 업체가 입력시킨 인명및사료 데이타를 못받을지 몰라. 이럴 경우 일일이 캡춰해야 되는데 좀 편하게 이 데이터를 자동수집할 방법은 없을까?
크롤링 봇으로 전체 리스트 페이지를 수집한 후, 그 수집된 HTML 페이지를 파싱해 데이타를 추출하는 프로그램을 개발해야할 것 같습니다. 파싱은 HTML 트리 분석 같은 복잡한 기술 없이 단순히 스트링 패턴 분석만으로도 충분할 것으로 보입니다. 아주 오래 전에 이와 비슷한 일을 해본 경험이 있어서인지 감회가 남다르네요.ㅎ