속성 vs 관계: 결정 가이드

Hook: "이 정보를 속성으로 저장할까, 별도 노드로 만들까?"

고객의 "거주 도시"를 어떻게 저장할까요?

• Option A: (:Customer {city: 'Seoul'})
• Option B: (:Customer)-[:LIVES_IN]->(:City {name: 'Seoul'})

정답은... 상황에 따라 다릅니다!

---

결정 프레임워크

속성으로 저장 (Property)

조건	예시
값이 단순하다 (문자열, 숫자)	이름, 나이, 가격
해당 값으로 탐색하지 않는다	설명, 메모
값의 종류가 매우 많다	전화번호, 주소
값이 자주 변경된다	재고 수량, 상태

별도 노드로 분리 (Relationship)

조건	예시
값에 추가 정보가 필요하다	도시 → 인구, 위치
해당 값으로 많이 검색/집계한다	카테고리, 브랜드
값의 종류가 제한적이다	등급, 상태
다른 엔티티와 관계가 있다	태그, 카테고리

---

실전 예제

예제 1: 고객 등급 (tier)

분석:

• 등급 종류: bronze, silver, gold, platinum (4개)
• 등급별 혜택, 할인율이 다름
• "Gold 고객 전체"를 자주 조회

결론: 혜택 정보가 필요하면 노드로 분리, 단순 라벨링이면 속성

예제 2: 주문 상태 (status)

분석:

• 상태: pending, confirmed, shipped, delivered, cancelled
• 상태 변경 이력이 중요
• 상태별 통계 필요

결론: 이력 필요하면 노드로 분리, 현재 상태만 필요하면 속성

예제 3: 상품 카테고리

분석:

• 카테고리는 계층 구조
• 카테고리별 상품 목록 자주 조회
• 카테고리 자체 정보 (설명, 이미지)

결론: 카테고리는 반드시 노드로 분리 (계층 + 탐색)

---

의사결정 플로우차트

---

Pitfall: 결정 실수

1. 모든 것을 속성으로

2. 모든 것을 노드로

3. 중간 지점 무시