주요 기능별 고려해야 할 사안
사용자 정보 저장
-아이디
-프로필 사진
-비밀번호
-팔로워
포스팅
-작성자
-작성 시각
-사진
-작성 내용
-해쉬태그
-좋아요
-댓글
해쉬태그
-해쉬태그명
-댓글에 달 수도 있음
-포스팅에 달 수도 있음
좋아요
-누가 좋아요를 눌렀는지?
-어떤 포스팅에 좋아요가 달렸는지?
댓글
-댓글 작성자
-작성자 사진
-작성 시각
-작성 내용
-좋아요
-댓글 달린 포스트
각 기능별로 스키마 작성해보기
사용자
사용자와 포스팅의 관계
한명의 사용자가 여러 개의 포스팅을 올릴 수 있다.
하지만 하나의 포스팅을 여러 명의 사용자가..아 요새는 또 공동 작업자 기능 있었지;;
요즘 인스타 기능까지 고려한다면 다대다 관계로 관리해야 할 것이다.
그렇다면 사용자와 작성한 포스팅을 칼럼으로 가지는 별도의 테이블을 또 만들어야 한다.
그런 기능을 고려하지 않는다면 그냥 일대다 테이블로 만들면 된다.
사용자와 댓글의 관계
한명의 사용자가 여러 개의 댓글을 달 수 있다.
하지만 하나의 댓글을 여러 명의 사용자가 쓸 수 없다.
따라서 사용자 테이블과 댓글은 일대다 관계로 관리.
사용자와 팔로워 관계
한명의 사용자가 여러 명을 팔로우할수도 있지만, 여러명의 사용자가 한명을 팔로우 할 수 있다. 즉 다대다 관계이다.
위 그림은 수정이 될 필요가 있음. 사용자와 팔로워 관계를 보여주는 follow-follwer 테이블 별도로 작성하여야 한다. 
포스트
포스팅과 좋아요 관계(0308수정)
하나의 포스트는 여러 명의 사용자가 관리할 수 있다.
따라서 둘은 일대다 관계로 관리하는 것이 맞다
단 위 그림에서 알 수 있듯이 포스팅 당 전체 좋아요 개수는 포스트 테이블에 별도로 저장하고 있음을 알 수 있는데, 이는 포스트에 좋아요 개수를 직접 수정하는 데 걸리는 시간이, post likes 테이블을 이용해서 좋아요 개수를 계산하는 것보다 더 짧기 때문일 것이다..
포스트와 해쉬태그의 관계
하나의 포스트가 여러 개의 해쉬태그를 쓸 수 있고, 하나의 해쉬태그가 여러 개의 포스팅에 쓰일 수 있다.
따라서 이 둘은 다대다 관계이며, 포스트와 해쉬태그 칼럼을 별도로 모아둔 테이블 필요하다
포스트와 댓글의 관계
하나의 포스트에는 여러 개의 댓글이 달릴 수 있다.
하지만 하나의 댓글을 여러 개의 포스트에 달 수 없다. 포스트와 댓글의 관계는 일대다로 관리하자.
댓글
댓글과 좋아요 관계
하나의 댓글에 좋아요를 여러 사람이 누를 수 있다.
또한 한명의 사람이 여러 개의 댓글에 좋아요를 누를 수 있다.
누가 어떤 댓글에 좋아요를 눌렀는지에 대한 정보를 저장할 필요가 있으니까 댓글과 좋아요를 누른 사람에 대한 테이블을 별도로 만들어야 한다.
댓글과 해쉬태그 관계
하나의 댓글이 여러개의 해쉬태그를 쓸 수 있고, 하나의 해쉬태그가 여러개의 댓글에 들어갈 수 있으니 다대다 관계로 정리하자.
*해쉬태그 테이블은 별도로 만든 이유
필드가 하나뿐이어서 댓글이나 포스팅 테이블에 넣을 수도 있었겠지만, 해쉬태그가 같은 것이 여러 개의 댓글이나 포스팅에 들어간 상황이고, 사용자가 그 해쉬태그를 수정했다고 해보자.
그러면 DB에서는 그 해쉬태그가 같은데도 여러 번 댓글/포스팅 테이블에 입력된 상황이니까 수정도 여러번 해야하고, 이 과정에서 실수도 생길 것이다. 따라서 하나의 독립된 테이블로 관리하는 게 맞다.
0308 추가작성
학습목표 기준으로 공부할것 (*그룹바이는 통계용 쿼리)
효율적인 스키마 작성법
-구현하는 기능 중심으로 스키마 디자인을 한다.
-테이블 속성이 비슷한 것들은 한데 묶어서 배치한다.
**RDBMS에서 관계 없는 독립된 테이블 있을 수 있다.
쿼리문 작성 요령
-서브쿼리를 과하게 남발하는 것은 좋지 못하다.(중첩 좋지 못하다)
-이럴 경우 차라리 조인 연산을 여러 개 사용하는 것이 나음.
-사내 컨벤션을 따르는 것이 적절
데이터 마이그레이션
하나의 운영환경에서 다른 운영환경으로 이동하는 것을 말한다.
여러 개발환경에서의 DB 변경 이력, 상태 히스토리 정보를 통일하거나, 이력을 저장해두어 데이터 유실에 대한 대비가 목적이다. (참고)
