[스프링부트 #10] 데이터베이스 테이블 설계의 철학과 관계 정리

1. 비즈니스 설계가 먼저다.

“비즈니스를 이해하지 못하고 설계하는 건, 눈 가리고 그림 그리는 것과 같다.”

2. 테이블은 “명사”다 → 명사 설계가 기본

“명사를 먼저 생각하지 않고, 동사를 먼저 설계하면 조진다”

3. 테이블 간의 관계를 파악하는 핵심 개념

고객 하나는 상품을 몇 개 구매할 수 있을까 ?

• 이것은 "고객 테이블의 한 로우가, 구매 테이블에 몇 개의 로우와 연결되는가"를 묻는 것이다.

• 즉, 항상 하나의 로우에서 출발해서, 상대 테이블의 몇 개의 로우와 관계가 있는가를 생각해야 한다.

4. 관계별 설계 방식 정리

1 : 1 관계

N : 1 관계

N : N 관계

5. 데이터베이스의 원자성

"컬럼에는 반드시 로우당 하나의 값만 들어가야 한다."

• 하나의 셀에는 리스트처럼 여러 개를 넣으면 안 됨.

• 이를 지키기 위해서는 참조키를 활용해 다른 테이블과 연결해야 함.

• N:1에서 N에 FK를 넣는 이유도 이 원자성 때문이다.

6. 실전 테이블 설계 팁

• 참조키(FK)는 반드시 유일한 키(PK)를 참조해야 한다.

• 수정이 없다면, 중복을 허용하고 조인 없이 데이터를 저장하는 것도 나쁘지 않다.
• 예시: 주문 당시의 고객 이름이나 주소를 별도 테이블 참조 없이 주문 테이블에 직접 저장

• 조인이 필요 없으면 성능상 이점 있음.

7. VIEW = 조인 결과

• 여러 테이블을 조인해서 보여주는 가상의 테이블이 VIEW

• 복잡한 조인 결과를 뷰로 만들어서 재사용하면 쿼리 관리가 편해진다.

8. 게시판 예제: User ↔ Board 관계 설계

• 관계: 1명의 User가 여러 개의 Board 작성 가능 → 1:N

• 따라서 Board 테이블에 user_id(FK) 를 둔다.

• 관계 정의에 맞게 조인도 가능하고, 원자성도 지켜진다.

관계 설계는 결국 "비즈니스 흐름"과 "로우 간의 연결"을 정확히 파악해야 한다.

• 명사 설계를 우선하고, 관계가 복잡해질 때 동사 테이블을 도입

• 무조건 조인을 남용하지 말고, 비즈니스에 따라 중복이 오히려 이득일 수도 있다.

• FK는 어디에 넣을지 원자성을 기준으로 판단