[TIL] 2020.09.11 Starbucks serise_ modeling - crawling - dumping

dev.soo·2020년 9월 11일
0

modeling & crawling

목록 보기
3/3
post-thumbnail

스타벅스 음료의 모델링-크롤링-Django 모델링-데이터 덤핑을 완료했다.
그 과정에서 예상치 못했던 문제들을 몇 번 맞닥드려서 생각보다 시간을 많이 소요했다. 어떤 건 문법에 익숙치 않아서, 어떤 건 전반적인 흐름을 몰라서 앞선 단계에서 아무생각 없이 했던 게 나중에 문제가 되는 경우였다.

1. 모델링 vs 크롤링 vs Django models

맨 처음 모델링을 할 때, 관계에만 중심을 두고 일대일/다대다/일대다 관계위주로 작성했다. 그리고 눈에 보이는대로 데이터 타입을 설정해 주었다.

그런데 실제로 크롤링을 하다 보니 내가 생각했던 것과 달랐다.

예를 들어서, 음료-알레르기 유발 요인 은 다대다 관계로 설정하였는데, 실제로 크롤링을 할 때 "알레르기 유발요인: 우유/밀" 처럼 str 으로 되어있는 걸 알게 되었다.
시간을 좀 더 들여서 "/"를 기준으로 하나씩 리스트화 해야 하나 고민했지만 우선 덤핑연습을 위해 그냥 스트링타입으로 바꿔주고, Product 에 이름/설명처럼 알레르기를 추가해주었다. [하나씩 리스트화 해서 저정하는 거 연습해보기!]

그냥 크롤링만 하는 거라면 편하게 다 긁어왔을텐데, 이 데이터를 잘 세분화해서 저장하면 프론트에서 작업을 두 번 할지언정 무적의 데이터로 언제고 홈페이지를 리뉴얼 할 수 있지 않을까?

크롤링을 할 때도, 페이지 단위로 했는데 막상 이 csv를 덤핑하려니 여러개의 csv 에 있는 데이터를 FK 로 써야 하는 문제가 생겨서 더더 어려웠다. 결국 덤핑 연습을 위해 크롤링한 데이터를 최대한 묶어서 하나의 csv 파일로 저장할 수 있도록 수정했고 이 파일로 덤핑을 마쳤다. csv 파일을 생성할 때는 크롤링 위주의 파일보다는 덤핑 위주의 파일을 만들자!

2. CSV 파일의 1열

이것도 아무 생각없이 1열에 col 에 대한 정보를 줘야 한다고 생각해서, 저장한 csv 파일을 다시 열어서 1열을 추가해주었다. 결론적으로 나의 csv 생성을 위한 파일이 지저분해지고 파일이 두 개씩 생겼더랬다.

막상 데이터 덤핑을 할 때는 유효하지 않은 1열을 제거하는 코드를 한 줄 더 쳐야 했다.

세 번째 줄의 next(data_reader, None) 을 추가하여 첫 열 건너뛰기를 해줬다.
나중에는 결국 csv 작성할 때 헤더 추가하는 코드와 next(~ 코드를 다 제거해줬다.
[언제 헤더를 추가해서 저장하는 게 좋은지 알아보기!]

3. 비밀번호의 길이

이건 다른 프로젝트의 회원가입쪽에서 생긴 문제였는데, 이전 포스트에서도 언급했지만 암호화 이후에는 비밀번호의 길이가 아주 길어지니까 max_length 를 넉넉하게 해주어야 한다.

4. 데이터 덤핑 연습할 때

어떤 테이블의 데이터를 전체 삭제하고 다시 쓰고 싶은데 mysql 상 삭제가 되지 않았다.

ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails

그럴 때는, FK 설정을 잠시 제거하고 데이터를 삭제한 후 다시 설정하면 된다.

mysql> SET foreign_key_checks = 0;

mysql> drop table TABLENAME

mysql> SET foreign_key_checks = 1;

[mysql 문법 사용해서 데이터 조작해보기!]

5. text 추출 시 \n 삭제하고 저장하기

.csv 나 db에서 줄바꿈이 섞여있으면 괜히 마음이 불편해서 삭제하고 저장했는데, 또 그러려고 시간을 들였는데, 프론트와 작업할 때 그대로 넘겨줘야 할 일이 왕왕 있을 것도 같다. 크롤링을 할 때, 모델링을 짤 때, 언제나 목적을 잊지 말아야 한다.
나같은 경우 프론트와 프로젝으로 웹 클론을 하게될텐데, 그러면 그대로 저장해줬어야 한다.

0개의 댓글