2022/03/01 스키마 API 작성

스키마 작성

사용 툴 : https://dbdiagram.io/home

CREATE TABLE `users` (
  `id` int PRIMARY KEY,
  `email` varchar(255),
  `password` timestamp,
  `nickname` int
);

CREATE TABLE `post` (
  `id` int PRIMARY KEY AUTO_INCREMENT,
  `user_id` int,
  `image` img,
  `text` varchar(255),
  `total_Likes` int,
  `total_commet` int,
  `created_at` timestamp
);

CREATE TABLE `Post_comments` (
  `id` int PRIMARY KEY AUTO_INCREMENT,
  `user_id` int,
  `post_id` int,
  `commnet` varchar(255),
  `created_at` timestamp
);

CREATE TABLE `hashtag` (
  `id` int PRIMARY KEY AUTO_INCREMENT,
  `tagname` varchar(255)
);

CREATE TABLE `post_hash` (
  `id` int PRIMARY KEY AUTO_INCREMENT,
  `post_id` int,
  `hashtag_id` int
);

CREATE TABLE `post_likes` (
  `id` int PRIMARY KEY AUTO_INCREMENT,
  `user_id` int,
  `post_id` int
);

CREATE TABLE `music_data` (
  `id` int PRIMARY KEY AUTO_INCREMENT,
  `title` varchar(255),
  `musician` varchar(255),
  `genre` varchar(255),
  `url` link
);

CREATE TABLE `post_music_list` (
  `id` int PRIMARY KEY AUTO_INCREMENT,
  `post_id` int,
  `musicdata_id` int
);

ALTER TABLE `users` ADD FOREIGN KEY (`id`) REFERENCES `post` (`user_id`);

ALTER TABLE `users` ADD FOREIGN KEY (`id`) REFERENCES `Post_comments` (`user_id`);

ALTER TABLE `post` ADD FOREIGN KEY (`id`) REFERENCES `Post_comments` (`post_id`);

ALTER TABLE `post` ADD FOREIGN KEY (`id`) REFERENCES `post_likes` (`post_id`);

ALTER TABLE `users` ADD FOREIGN KEY (`id`) REFERENCES `post_likes` (`user_id`);

ALTER TABLE `music_data` ADD FOREIGN KEY (`id`) REFERENCES `post_music_list` (`musicdata_id`);

ALTER TABLE `post_music_list` ADD FOREIGN KEY (`post_id`) REFERENCES `post` (`id`);

ALTER TABLE `post` ADD FOREIGN KEY (`id`) REFERENCES `post_hash` (`post_id`);

ALTER TABLE `hashtag` ADD FOREIGN KEY (`id`) REFERENCES `post_hash` (`hashtag_id`);

1. music_data를 가져오는 것을 Spotify API에서 받아오는 외부 데이터로 대체할지 논의했다.
2. user 테이블에 salt 값을 넣는 것에 대해 토의했으나 이번 프로젝트에서 해쉬값, 솔트 값을 넣는 것은 
3. music_data를 바로 post의 column으로 넣는 것 vs music_data테이블과 post 테이블 사이에 post_music_list 테이블을 넣는 것 사이에서 의견충돌이 있었다.
   
   • 나의 의견 : 데이터 테이블은 순수하게 그 데이터만 담겨있어야한다는 지론을 펼쳤다. 여러 테이블을 만들 수 밖에 없는 점에 대해서 설득하는 것이 쉽지 않았으나, 팀 내에서 내 의견이 받아들여져서 결국 music_data와 post의 아이디 값을 참조하는 post_music_list 테이블이 유지될 수 있었다. (다대다 구조)
   • 느낀 점 : 테이블과 테이블 사이의 관계를 명확히 알고 설명할 수 있는 능력이 필요하다는 것을 깨달았다. 

1:1 관계 : 1대 1로 나타낼 수 있는 관계라면 직접 필드에 저장하는 게 나을 수 있다 1:N(one-to-many 일대 다)관계 : 하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우 N에 해당하는 테이블이 foreign key가 될 때 문제점 한 레코드에 외래 키가 다중 존재할 경우 필드 공간을 예측할 수 없어 공간 부족 문제가 생길 수 있음. 한 열에 여러 값을 저장 시 상수시간(constant-time) 에 대한 검색 손실 발생. 여러 레코드를 만들 경우 정합성이 깨질 수 있음. 동일해야하는 데이터가 다중 존재함(하나의 출처라 볼수 없음) 해결방안 : 1에 해당하는 테이블이 foreign key가 되어야함. N:N(many-to-many 다대 다)관계 : 여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 관계가 있는 경우 조인 테이블(join table) : 같은 테이블에 담으면 중복이 되어 낭비. 따로 관리하는 것이 더 편리함. 다대다 관계를 위한 테이블. 좌표계와 비슷한 형태로 데이터 연결 문제 해결.

 

 

 

API 문서 작성

사용 툴 : https://www.gitbook.com

GitBook - Where software teams break knowledge silos.

현재 작성 중인 API 문서 : https://app.gitbook.com/o/LRakOsh6mYykzxRI0iij/s/6ifJhZJO4cHtLy9o0WiG/group-1/music-flower

GitBook

1. HTTP 메소드, params를 활용하여 API를 작성하는 법을 익혀야겠다.(Section2 과제 및 노션 정리한 것 공부)
2. 서버와 클라이언트 사이에 토큰이 교환되는 플로우에 대해 다시 익히고 공부해야겠다. (Section3 과제 및 노션 정리한 것 공부)