1. 소개
같은 지역에 속해 있는 사람들과 주변 상권에 대한 정보를 공유할 수 있는 서비스이다. 네이버지도나 카카오맵과 같은 지도 서비스에서는 얻기 힘든, 좀 더 사소하지만 식당 결정에는 영향을 미치는 정보들을 친구들과 공유하는 것을 목표로 한다. 친구 관계를 맺은 사람들과 공유하기 때문에 신뢰도가 높고 정확한 정보를 얻을 수 있을 것으로 기대한다.
2. 아이디어 구상 계기
군대를 전역하고 2년 만에 다시 학교로 돌아가보니 주변 상권이 너무 많이 바뀌어 있었다. 없어지고 새로 생긴 식당도 많았으며 기존의 식당들도 메뉴 구성이나 가격 등에 변화가 있어 내 기억과는 사뭇 달라서 당황한 적도 있었다. 바뀐 정보들을 친구들과 공유하면 이렇게 식당에서 당황하는 일을 줄이고 유용하게 활용할 수 있지 않을까?라는 생각에 프로젝트를 구상하게 되었다.
3. 기능
먼저, 핵심 기능은 식당이나 카페, 술집 등 등록하고 그 가게에 대한 tip을 작성하고 공유하는 것이다. 가게는 식당, 카페, 술집, 기타 카테고리로 분류할 수 있고 가게에 대해 작성한 tip은 자신과 친구 관계에 있는 사람들에게만 공유된다. 가게에 대해 카테고리별로 분류가 가능하고 가게명으로 검색 또한 가능하다.
친구 관계를 맺기 위해서는 로그인이 필요하며 기본적으로 구글, 네이버, 카카오 계정으로 로그인이 가능하며 서비스 내에서 사용할 닉네임을 설정할 수 있다. 이 닉네임을 이용하여 친구 신청이 가능하다.
4. DB 구조 및 설계 이유
Database 구조는 다음과 같다.
1. member
- 사용자의 id, email, name, nickname, provider를 필드로 가진다.
- id는 기본키이며 name은 Name은 구글, 네이버, 카카오 계정에 등록되어 있는 이름이고 nickname은 서비스 내에서 사용할 닉네임이다.
- Name은 수정이 불가능하고 nickname은 수정가능하다.
- Provider를 따로 둔 이유는, 카카오 계정이라 해도 이를 네이버 계정으로 가입한 경우 email은 naver 이메일을 사용한다. 따라서 email이 같은 경우, email 필드만으로는 카카오 계정, 네이버 계정을 구분할 수 없다. 이를 provider를 통해 kakao, naver, google을 명시하여 구분할 수 있도록 했다.
2. post
- id(PK), storeName, storeType(카테고리), writer_id 필드가 있다.
- 이름 그대로 가게명, 가게 분류(카테고리), 작성자 ID를 저장한다.
- storeType은 소스 코드에서는 enum 타입을 사용했다.
3. tip
- id(PK), comment, writer_Id,post_id 필드가 존재한다.
- Comment는 가게에 대한 tip이고, post와의 관계매핑을 위해 post_id 필드를 추가했다.
- Post와 tip은 1:N 양방향 관계로 설계했다.
4. friend
- id(PK), member1_id, member2_id 필드가 존재한다.
두 member의 id를 필드로 가지며,
Friend 관계를 위와 같이 저장하는데, member A가 B에게 친구신청을 한 경우, friend db에는 (A,B)와 같이 저장된다. (B,A)는 저장되지 않는다. 따라서, 친구 관계를 불러오기 위해서 아래와 같이 A의 친구들을 불러오기 위해서는 friend db에서 (A,x), (x,A) 컬럼의 x를 모두 리턴하도록 구현했다.
5. message
- - DTYPE, id(PK), sender_id(보낸 사람), receiver_id(받는 사람), message_type, contents 필드가 있다.
- message_type과 contents는 서비스의 기능을 더 확장할 경우를 대비해서 만든 필드이며
- message_type은 소스 코드에서 enum 타입을 사용했으며
- contents는 친구 신청 및 수락 메시지에서는 사용하지 않는다.
- 아래 사진과 같이 DTYPE을 통해 newMessage, oldMessage를 구분한다.
- Message를 new, old로 구분해야 했는데 어떻게 설계할지 고민하다가 단일 테이블 전략을 알게 되어 적용시켜 보았다.
New, old message를 구분한 이유는 아래 사진과 같이 받은 메시지를 출력할 때, newMessage만 출력하기 위해서이다.
사용자가 확인한 메시지는 위 코드를 통해 newMessage를 oldMessage로 업데이트해 주었다.
5. 파일 구조
파일 구조는 다음과 같다. 이들은 아래와 같은 의존관계를 가진다.
프로젝트의 엔티티들은 다음과 같은 관계를 맺고 있다. 인텔리제이의 다이어그램 그려주는 기능을 처음 써보고 신기해서 넣어봤다.
6. 향후 계획
- 코드 구현은 거의 완료했는데 페이지 디자인을 해보니 내가 디자인 감각이 부족하다는 사실을 절실히 깨달았다. 원래는 혼자 공부해 가며 배포까지 마무리하려 했지만 디자인이 좀…. 많이 아쉬워서 flutter를 공부하는 친구와 협력을 하기로 했다. 이제 개발 서버를 구축하고 자동 배포 환경을 만드는 방법을 공부할 계획이다.
https://github.com/HyoBN/ourmap
'Project' 카테고리의 다른 글
| [파이썬] 채팅 프로그램 제작하며 공부했던 내용 (2) | 2022.03.13 |
|---|---|
| [파이썬] 채팅 프로그램 (2) | 2022.01.01 |
| [파이썬] 소켓 기반 채팅 프로그램 제작하면서 겪었던 에러 (0) | 2021.09.28 |
