연결 테이블의 진짜 가치가 드러나는 부분은 **"관계에 속한 속성"**을 저장할 수 있다는 점이다.

주문-상품 예시에 다시 돌아가 보자.

• quantity (주문 수량)
• order_price (주문 당시 가격)

이 두 값은 어디에 속하는 정보일까?

• 주문 테이블(orders)에는 전체 주문에 대한 정보만 들어있다.
  • 주문 하나에 여러 상품이 들어갈 수 있어서, 각각의 상품 수량을 주문 테이블에 직접 넣을 수 없다.
• 상품 테이블(product)에는 현재 상품 정보만 들어있다.
  • 상품 가격은 언제든 바뀌므로, 과거 주문 당시 가격을 현재 가격으로 덮어쓰면 안 된다.

결局 **"어떤 주문에서, 어떤 상품을, 몇 개, 얼마에 샀는가"**라는 정보는 두 엔티티의 관계 속에만 존재한다.

그래서 이 정보들을 연결 테이블 order_product의 속성으로 옮긴다.

CREATE TABLE order_product (
  order_product_id BIGINT PRIMARY KEY,
  order_id         BIGINT NOT NULL,
  product_id       BIGINT NOT NULL,
  order_price      INT    NOT NULL,  -- 주문 당시 가격
  quantity         INT    NOT NULL,  -- 주문 수량
  CONSTRAINT fk_order_product_order
    FOREIGN KEY (order_id)   REFERENCES orders(order_id),
  CONSTRAINT fk_order_product_product
    FOREIGN KEY (product_id) REFERENCES product(product_id)
);

정리하면, 다대다 관계를 설계할 때 항상 다음 질문을 던진다.

"두 엔티티의 관계 속에서만 의미를 가지는 속성이 있는가?"

• 있다 → 반드시 연결 테이블을 만들고 그 속성들을 그쪽에 둔다.
• 없다 → 그래도 물리적으로는 연결 테이블이 필요하지만, 컬럼은 두 FK 정도로만 단순하게 구성할 수 있다.