이번 주 한 일
- (팀과제)챌린지팀 결성 및 SA작성
- (팀과제) 챌린지팀 프론트, 백엔드 만들기
이번 주 할 일
- (팀과제) 부하테스트
- (팀과제) 부하테스트 툴 공부
- (팀과제) 프론트, 백엔드 코드 수정
NoSQL vs SQL
noSQL과 SQL의 차이는 뭘까?
SQL
- 관계형 DB. (RDBMS)
- 데이터 저장에 고정된 테이블 스키마 필요 O (스키마에 어긋나면 데이터 저장X)
- 조인 연산 사용 O
- 관계를 통해 여러 테이블에 분산
- ACID 속성(Atomicity, Cosistency, Isloation, Durabilty)
NoSQL
- 비관계형 DB.
- 데이터 저장에 고정된 테이블 스키마 필요 X
- 조인 연산 사용 X, 수평적으로 확장이 가능한 DBMS
- 관계 필요 X
NoSQL과 SQL의 용어 정리
❓테이블 스키마가 필요없다는게 무슨 말임?
둘 다 JSON형태로 { name : '아무개', 'age': 30, 'status' : 'live'} 데이터가 저장이 된다고 보자.
만약 SQL에서 테이블 스키마를 만드는데 name 과 age만 만들어 놓고 위와 같은 데이터를 입력한다고 하면 에러가 뜬다.
noSQL의 경우 저 데이터가 그냥 저장이 되고, { name : '아무개', 'age': 30 } 이렇게도 저장이 되고, { name : '아무개', 'age': 30, 'status' : 'live', 'gender' = 'F'}로도 저장이 되는 것이다.
❓그럼 언제 뭘 쓰면 좋아?
- SQL 데이터베이스 사용이 더 좋을 때
관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션의 경우
NoSQL에서는 여러 컬렉션을 모두 수정해야 하기 때문에 비효율적
변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우
- NoSQL 데이터베이스 사용이 더 좋을 때
정확한 데이터 구조를 알 수 없거나 변경/확장 될 수 있는 경우
읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
데이터베이스를 수평으로 확장해야 하는 경우 (막대한 양의 데이터를 다뤄야 하는 경우)
사족: 나는 엑셀을 많이 써와서 그런가 SQL이 더 좋다..
[참고자료]
https://aws.amazon.com/ko/nosql/
https://gyoogle.dev/blog/computer-science/data-base/SQL%20&%20NOSQL.html
프론트와 백엔드 연결을 사실은 사전주차때 경험은 해봤으나 그때는 흐름이 어떤가 파악만 했지 실제로 와닿지는 않았다. 그렇게 주특기(nodejs)를 시작한 후로는 서버를 비즈니스 로직을 통해서 해당 기능을 구현하고 에러를 잡아내는 일에 집중했다. 그렇게 챌린지팀을 하게 되었는데 버튼 하나만 구현해놓고 성능개선을 하려고 했는데 하다보니 api가 하나씩 늘어갔다. 어찌저찌 협의를 통해서 가장 최소로 구현하자고 하였고, 내가 프론트를 맡게 되었다. 프론트에 관심이 있어서 자청한 일이었지만 막상하려고 보니 뭐부터 할지 막막했다. 일단 제공해준 강의가 있었고, 지난 강의와 자료를 찾아가면서 하나씩 구현했다. 나는 툴이 바뀌어버리면 내가 배운 것과 새로 배우는 툴에 대해서 비교해가면서 파악을 해야하는데 시간이 꽤나 걸린다.
일단 하기로 했으니까.. 일단 한다..! 하면서 느낀건데 프론트랑 협업을 할 때는 특히 API명세서를 정말 섬세하게 짜야겠다. 서버에서 보낸 에러메시지가 자꾸 안떠서 이게 데이터가 어디있는건지 살펴보면 message로 보낸건줄 알았던걸 error로 보냈다거나 하는 일이 대부분이었다. 그래서 서버의 코드까지 수정하게 되었다.
그렇다. 사실 팀과제로 CRUD 구축을 다른 팀원이 하고 나는 프론트만 하게 되었는데 일이 굴러가는 순서에 익숙치않아서 토요일까지 마치기로 했었던 것이었다.
알았더라도 일단 거대한 틀만 짜놓고 데이터는 나중에 연결하면 된다라고 할 수도 있지만 나는 눈으로 확인하면서 해야겠기 때문에 CRUD까지 내가 하게 되었다...결국 풀스택...!
이렇게 배우는거지 뭐! 결국 대충 MVP만 해놓고 앞으로 조금씩 수정하기로 했다. 앞으로 프론트에서 에러가 나버리면 난 멘탈이 나갈 것 같지만...열심히 떡볶이로 멘탈을 부여잡아야겠다.
