DB 설계 - 논리적 모델링

[dev-hobin]

• 대리키써라
  자연키는 변경가능성에서 자유롭지 못하다. 대리키를 PK로 만들고 자연키는 유니크 제약조건 걸어라.
• DB에서 테이블끼리의 관계에 단방향은 없다.
• 외래키는 규칙을 강제할 수단이 된다.
  외래키가 없어 규칙을 DB 수준에서 강제할 수 없는 경우 애플리케이션 계층에서 하나의 트랜젝션으로 잘 묶어서 제약을 만족하는 코드를 짜야한다.
• 1:N 관계에서 외래키는 N 테이블이 가져야한다.
  1 테이블이 외래키 가져가면 나중에 PK 충돌난다.
• 1:1 관계는 관심사 분리, 확장성을 기준으로 따로 나눠놓은 결과물이다.
  아니라면 합치는 것이 낫다.
• 1:1 관계는 외래키 걸어준 테이블에 유니크 제약조건까지 함께 걸어줘야한다.
  안그러면 1:N 관계가 됨
• 1:1 관계에서 외래키는 보다 덜 사용하는 보조 테이블쪽에 둬라.
  주테이블이 외래키를 굳이 컬럼으로 가지고 있을 필요가 없다. -> 독립성 보장
  선택관계 표현이 명확히 됨 -> 주테이블이 NULL을 허용하는 외래키를 가질 필요가 없음
• N:M 관계는 연결 테이블을 만들어 1:N 관계로 테이블을 만들어 해결한다.
• 비식별 관계를 써라.
  식별관계 쓰면 확장성,유연성 떨어진다.
• 위의 내용과 반대되는 결정을 할 수도 있는데 트레이드 오프를 감수하는 극히 예외적인 상황일 것이다.

---

음.. 결국 PK 만들 때 거만하게 평생 불변할 조건이라고 생각하고 자연키를 한개 이상 엮어서 만들 생각하지 않기를 명심하면 자연스럽게 위의 내용을 생각해낼 수 있는듯하다?

이것만 주의하면 나머지는 직접 해보면서 잘못된 방향으로 가고 있을 때 묘한 이질감을 느끼겠지?

[yoonminsang]

db는 그냥 개인적으로 공부하시는건가요?

[dev-hobin]

네 시간 좀 있을 때 기본이라도 배워두려고요.
나중에 혼자서도 아이디어 있을 때 작은 서비스를 바로 만들어볼 수 있을 정도까지는 해보고 싶네요