Search
Duplicate
📌

정기회의 + 멘토링

회의 날짜
2021/08/04
회의 내용
회의 날짜_formatted
Aug 04
참여자

사전 질문 리스트

예상 멘토링 흐름
1.
이전 멘토링 후 타겟을 명확히 하는 작업이 계속 도돌이표를 찍으면서 진전이 없어서 일단 핵심 기능이라도 먼저 개발하는걸로 정함 (타겟은 나중에 명확히함)
2.
핵심 기능 : 지도상에 모임을 만들고 모임에 참가하는 기능
3.
기능 중심으로 마인드맵을 정리하고, 와이어프레임을 짜고, DB 구조를 짜보았음
4.
그런데 DB 구조에서 모임과 유저 사이의 관계를 어떻게 구현해야할지 잘 모르겠음
5.
참여 테이블을 1:1로 둘지 1:N으로 둘지? <- miro 보여주면서 설명
6.
이외에 DB 구조 잡을때 참고할것이나 고민해야할것이 있는지?
db구조는 경험치라서 사실 정답이 없다. 설계할떄 정답이라는게 없다.
1.
앞으로 클라우드 서비스를 정하고 어떤 DB를 쓸것인지 정할예정이다
2.
일단 개발비용이 적게 든다는 장점에 firebase 를 사용할것으로 생각중인데
3.
클라우드 서비스를 정할때 고려사항이 있는지? 다른 스타트업이나 대기업에서는 어떤걸 쓰는지? 요즘 트렌드?
4.
DB는 요즘 핫한 Nosql(몽고 db)을 쓸필요가 없다고 생각했다. 다양한 타입이 있는 postgresql 을 생각중인데, RDB중에서 어떤걸 쓰는게 좋은지..?
5.
또한 firebase에서는 realtime database를 제공해주는걸 써야하는데 DB 가 성격이 안맞는거 같아서 고민이다.

멘토링 내용 정리

DB 구조는 각자에 맞게 커스터마이즈 하는 것(정답은 없다)
한 이벤트에 대해서 꼭 한 번만 쿼리를 날려야 하는 것은 아님
우리 DB 구조 문제 없어 보임
firebase 사용하는게 좋을 것 같음
지금 서비스는 복잡한 DB 사용할 필요 없음
nosql(mongo DB) 우리랑 안맞음
몽고 : 문장내에서 비정형 데이터(ex. 트위터 글)를 쓰게 된다면 필요하지만 지금 우리는 정형 데이터 밖에 없기 때문에 몽고 db를 쓸 필요가 없다.
어떠한 DB 사용해도 가능(RDB 중에서 쓰기)
mysql(maria DB)이 쉬우니까 그거 써도됨
다른 DB들
빅데이터 처리는 GCP가 유리
많이 사용되는 것은 AWS
고민은 충분히 한 것 같으니 결정해라!
공부보다는 프로젝트에 집중해라? 고민되네요...
참여 테이블
모임 수 증가함에 따라 볼륨이 너무 커지는 것 아닌가
데이터가 많아지는게 문제? 테이블이 많아지는게 문제? 레코드 많아지는게 문제?
테이블 많아지는 것은 전혀 문제 없다
무엇을 기준(유저, 모임)으로 테이블을 나누어야 하는지
비슷한 예시: 수강과목-수강학생
결론: 볼륨 커지는것에 대한 걱정은 나중에 해도 된다 ^^
정규화 해보기
null 처리
중복데이터 처리
DB 쿼리문 기초적인 거라도 직접 짜보기
live demo 를 한번해봐라
일정 잡아보기 !
구 dbguide.net => 데이터 온에어 dataonair.or.kr 한국데이터베이스 진흥원 에서 명칭 변경 => 한국데이터산업진흥원