DBModeling

1차 DB 모델링

<수정해야할 것>

Note : json 형식

HashTag : 별도테이블로 분리 -> 입력만하는게 아니라 검색도해야하니까

not null / unique 추가하기

music에 있는 block은 외래키가아니라 복사개념

2차 DB 모델링

unique : nickname

<질문할 것>

물리이름을 짧게 해야하는 이유

검색할 경우가 있을때 table 분리?

=> 어떤 블럭이 music을 구성하는지 알고싶을때 music에서 component를 검색할 일이 생긴다

식별 or 비식별 (빨간선,초록선)

foreing key,unique : 자동으로 index 걸림

cmpt column: varchar 로 하기에 너무 작지 않겠니? json으로 받을거니까 (max >> oracle : 400byte, mySQL : 250byte?) : 넘어갈수있으니까 clob 

charater large of object

<3차 모델링>

Emotion도 검색해야 하니까 테이블 빼내기

Hash, Emotion을 식별해야 할 일 없어서 PK 뺌

user-block, user-music의 relation을 zero-or-more 에서 one-or-more로 변경

- Foreign Key를 null 허용 하면 parent(Block - 참조되는 테이블)가 delete 되도 child(Block_emotion - 참조하는 테이블)가 남음

- dummy data : 테스트용 데이터 (dummy : 자동차 사고 테스트의 인형처럼)

<4차 모델링>

- Emotion table 식별관계로 만들기, 복합키 생성

- Hash를 관리할 일이생길지도 몰라 지금당장 필요없어도 PK 만들기

- 결합인덱스 

인덱스 레인지 스캔 (2개 컬럼으로 인덱스 범위 스캔)

인덱스 레인지 스캔 (1개 컬럼만 이용해 인덱스 범위 스캔후 나머지 한개 컬럼은 필터조건)

참고 : http://d2.naver.com/helloworld/1155

<5차 모델링>

- USER의 PASSWORD는 SHA를 이용하여 저장 (SHA를 이용하면 64 byte가 됨)

- email unique

- unique index= unique 제약/ unique만 따로할 수 없음

- email address를 PK로 주는 것은 바람직 하지 않다 => String을 PK로 주어서 검색등을 하면 성능이 저하됨

- 블럭 크기 시간조절 가능, 등록일 저장