ORM과 SQL의 균형

1. 세분성 (Granularity)
   객체: Address를 별도 클래스로 분리
   RDB:  users 테이블에 address 컬럼으로 포함

2. 상속 (Inheritance)
   객체: Employee → Manager, Developer 상속
   RDB:  상속 개념 없음 → 단일 테이블 / 조인 전략 필요

3. 동일성 (Identity)
   객체: == (메모리 주소), equals() (내용 비교) 두 가지
   RDB:  PK 하나로 식별

4. 연관 관계 (Associations)
   객체: 참조(단방향/양방향)
   RDB:  외래 키(항상 양방향 접근 가능)

5. 탐색 (Navigation)
   객체: order.getUser().getAddress() 그래프 탐색
   RDB:  JOIN으로 한 번에 조회해야 효율적

┌─────────────────────────────────────────────────────────────┐
│            Full ORM (Active Record / Data Mapper)           │
│                                                             │
│  JPA/Hibernate  │  Django ORM │  TypeORM  │  Sequelize      │
│  (Java)         │  (Python)   │  (TS/JS)  │  (JS)           │
│                                                             │
│  * 엔티티 매핑, 관계 관리, 변경 감지                        │
│  * 1차/2차 캐시, Lazy/Eager Loading                         │
│  * 마이그레이션 자동 생성                                   │
├─────────────────────────────────────────────────────────────┤
│               Lightweight ORM / Query Builder               │
│                                                             │
│   Prisma    │   Knex.js   │  MyBatis  │  SQLAlchemy Core    │
│   (TS)      │   (JS)      │  (Java)   │  (Python)           │
│                                                             │
│  * SQL에 더 가까운 인터페이스                               │
│  * 세밀한 쿼리 제어 가능                                    │
│  * 학습 곡선이 낮음                                         │
└─────────────────────────────────────────────────────────────┘

┌── EntityManager ────────────────────────────────┐
│                                                 │
│   영속성 컨텍스트 (Persistence Context)         │
│   ┌─────────────────────────────────────┐       │
│   │  1차 캐시 (Identity Map)            │       │
│   │  ┌──────────────────────────────┐   │       │
│   │  │ @Id=1 → User("홍길동")       │   │       │
│   │  │ @Id=2 → User("김철수")       │   │       │
│   │  └──────────────────────────────┘   │       │
│   │                                     │       │
│   │  쓰기 지연 SQL 저장소               │       │
│   │  ┌──────────────────────────────┐   │       │
│   │  │ INSERT INTO users ...        │   │       │
│   │  │ UPDATE users SET ...         │   │       │
│   │  └──────────────────────────────┘   │       │
│   │                                     │       │
│   │  변경 감지 (Dirty Checking)         │       │
│   │  ┌──────────────────────────────┐   │       │
│   │  │ 스냅샷 vs 현재 엔티티 비교   │   │       │
│   │  └──────────────────────────────┘   │       │
│   └─────────────────────────────────────┘       │
│                                                 │
│   flush() → DB에 SQL 전송                       │
│   commit() → 트랜잭션 확정                      │
└─────────────────────────────────────────────────┘

비영속 (new/transient)
  │  persist()
  ▼
영속 (managed)  ←── merge()
  │                     ▲
  │  detach()           │
  ▼                     │
준영속 (detached) ──────┘
  │
  │  remove()
  ▼
삭제 (removed)

* 영속 상태의 엔티티만 변경 감지 대상
* 준영속 엔티티를 수정하면 merge()로 다시 영속화 필요
* flush() 시점에 변경 감지 → UPDATE SQL 자동 생성

주문 목록 조회 (10건)

1. SELECT * FROM orders LIMIT 10;       ← 1번 쿼리 (주문 목록)

2. SELECT * FROM users WHERE id = 1;    ┐
3. SELECT * FROM users WHERE id = 2;    │
4. SELECT * FROM users WHERE id = 3;    │ N번 추가 쿼리!
5. SELECT * FROM users WHERE id = 4;    │ (각 주문의 사용자 조회)
...                                     │
11. SELECT * FROM users WHERE id = 10;  ┘

총 11번 쿼리 (1 + N)
→ 주문이 1000건이면 1001번 쿼리!

방법 A: JOIN으로 한 번에 (Fetch Join)
SELECT o.*, u.* FROM orders o
JOIN users u ON o.user_id = u.id
LIMIT 10;
→ 1번 쿼리

방법 B: IN 절로 배치 조회
1. SELECT * FROM orders LIMIT 10;
2. SELECT * FROM users WHERE id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
→ 2번 쿼리

────────────────────────────────────────────────
JPA (Java) - Fetch Join
────────────────────────────────────────────────
@Query("SELECT o FROM Order o JOIN FETCH o.user")
List<Order> findAllWithUser();

-- 또는 @EntityGraph
@EntityGraph(attributePaths = {"user"})
List<Order> findAll();

-- 또는 @BatchSize (IN절 배치)
@BatchSize(size = 100)
@OneToMany(mappedBy = "order")
private List<OrderItem> items;

────────────────────────────────────────────────
Django (Python) - select_related / prefetch_related
────────────────────────────────────────────────
# FK/OneToOne → JOIN (select_related)
Order.objects.select_related('user').all()

# ManyToMany/Reverse FK → 별도 쿼리 (prefetch_related)
Order.objects.prefetch_related('items').all()

────────────────────────────────────────────────
TypeORM (TypeScript) - relations / QueryBuilder
────────────────────────────────────────────────
// relations 옵션
orderRepo.find({ relations: ['user'] })

// QueryBuilder LEFT JOIN
orderRepo.createQueryBuilder('order')
  .leftJoinAndSelect('order.user', 'user')
  .getMany();

────────────────────────────────────────────────
Prisma (TypeScript) - include
────────────────────────────────────────────────
prisma.order.findMany({
  include: { user: true, items: true }
})

@Query("SELECT new com.example.OrderDto(o.id, o.amount, u.name)
        FROM Order o JOIN o.user u")
List<OrderDto> findOrderDtos();

장점
* N+1 문제 원천 차단
* 필요한 컬럼만 SELECT → 네트워크/메모리 절약
* 실무에서 복잡한 조회 화면에 권장

단점
* 엔티티가 아니므로 변경 감지 불가
* 화면별 DTO 클래스 증가

┌──────────────┬──────────────────────┬──────────────────────┐
│              │ Lazy Loading         │    Eager Loading     │
├──────────────┼──────────────────────┼──────────────────────┤
│     시점     │ 실제 접근 시 조회    │ 부모 조회 시 함께    │
│   쿼리 수    │ 접근할 때마다 발생   │ JOIN 1번 또는 IN 2번 │
│ 초기 로딩    │         빠름         │ 느릴 수 있음         │
│ N+1 위험     │         높음         │         없음         │
│    메모리    │ 필요한 것만 로드     │ 전체 로드            │
│ JPA 기본값   │ @ManyToOne: EAGER    │ @OneToMany: LAZY     │
│     권장     │ 글로벌 기본값        │필요한 곳만 Fetch Join│
└──────────────┴──────────────────────┴──────────────────────┘

실무 전략:
* 글로벌: 모든 연관관계를 LAZY로 설정
* 필요한 곳: JPQL Fetch Join 또는 @EntityGraph
* API 응답: DTO 직접 조회

────────────────────────────────────────────────
JPA - Native Query
────────────────────────────────────────────────
@Query(value = "SELECT * FROM users WHERE email = :email",
       nativeQuery = true)
User findByEmail(@Param("email") String email);

// EntityManager 직접 사용
List<Object[]> results = em.createNativeQuery(
    "SELECT u.name, COUNT(o.id) " +
    "FROM users u JOIN orders o ON u.id = o.user_id " +
    "GROUP BY u.name HAVING COUNT(o.id) > 5"
).getResultList();

────────────────────────────────────────────────
Django - raw() / connection.cursor()
────────────────────────────────────────────────
# raw() - 모델 인스턴스 반환
users = User.objects.raw(
    'SELECT * FROM users WHERE email = %s', [email]
)

# cursor - 완전한 Raw SQL
from django.db import connection
with connection.cursor() as cursor:
    cursor.execute("SELECT COUNT(*) FROM orders")
    row = cursor.fetchone()

────────────────────────────────────────────────
Prisma - $queryRaw
────────────────────────────────────────────────
const users = await prisma.$queryRaw`
  SELECT u.name, COUNT(o.id) as order_count
  FROM users u
  JOIN orders o ON u.id = o.user_id
  GROUP BY u.name
  HAVING COUNT(o.id) > 5
`;

────────────────────────────────────────────────
TypeORM - query()
────────────────────────────────────────────────
const results = await dataSource.query(
  `SELECT * FROM users WHERE email = $1`, [email]
);

1. 쿼리 로그 확인
   ┌─────────────────────────────────────────────┐
   │ spring.jpa.show-sql=true                    │
   │ spring.jpa.properties.hibernate.format_sql  │
   │  =true                                      │
   │ logging.level.org.hibernate.SQL=DEBUG       │
   │ logging.level.org.hibernate.type            │
   │  .descriptor.sql=TRACE  ← 바인딩 파라미터   │
   └─────────────────────────────────────────────┘
   → 개발 중 항상 켜두고 N+1 발생 여부 확인

2. 페이징 + Fetch Join 주의
   * 컬렉션(1:N) Fetch Join + 페이징 시
     → Hibernate가 메모리에서 페이징 (위험!)
   * 해결: @BatchSize 또는 DTO 조회

3. OSIV (Open Session In View) 설정
   * OSIV=true: 뷰 렌더링까지 영속성 컨텍스트 유지
     → 편리하지만 DB 커넥션 오래 점유
   * OSIV=false: 서비스 계층에서만 영속성 컨텍스트
     → 커넥션 빨리 반환, LazyInitException 주의
   * API 서버 권장: OSIV=false

4. 벌크 연산
   * 수천 건 UPDATE → em.createQuery().executeUpdate()
   * 벌크 연산 후 영속성 컨텍스트 초기화 필수
     → em.flush(); em.clear();

5. 2차 캐시 활용
   * 자주 조회, 변경 적은 데이터 → 2차 캐시 적용
   * @Cacheable, EhCache / Redis 연동

────────────────────────────────────────────────
Knex.js (JavaScript)
────────────────────────────────────────────────
const orders = await knex('orders')
  .join('users', 'orders.user_id', 'users.id')
  .select('orders.id', 'users.name', 'orders.amount')
  .where('orders.amount', '>', 1000)
  .orderBy('orders.created_at', 'desc')
  .limit(20);

// 생성 SQL:
// SELECT orders.id, users.name, orders.amount
// FROM orders
// JOIN users ON orders.user_id = users.id
// WHERE orders.amount > 1000
// ORDER BY orders.created_at DESC
// LIMIT 20

────────────────────────────────────────────────
SQLAlchemy Core (Python)
────────────────────────────────────────────────
from sqlalchemy import select, func

stmt = (
    select(orders.c.id, users.c.name,
           func.sum(order_items.c.price).label('total'))
    .join(users, orders.c.user_id == users.c.id)
    .join(order_items, orders.c.id == order_items.c.order_id)
    .group_by(orders.c.id, users.c.name)
    .having(func.sum(order_items.c.price) > 10000)
)

────────────────────────────────────────────────
QueryDSL (Java) - JPA와 함께 사용
────────────────────────────────────────────────
List<OrderDto> results = queryFactory
    .select(Projections.constructor(OrderDto.class,
        order.id, user.name, order.amount))
    .from(order)
    .join(order.user, user)
    .where(order.amount.gt(1000)
        .and(order.status.eq(OrderStatus.COMPLETED)))
    .orderBy(order.createdAt.desc())
    .offset(0).limit(20)
    .fetch();

개발자가 스키마 변경 시

1. 마이그레이션 파일 생성
   └─ V001__create_users_table.sql
   └─ V002__add_email_to_users.sql
   └─ V003__create_orders_table.sql

2. 버전 관리 (Git)에 커밋

3. 배포 시 자동 적용
   └─ 현재 DB 버전 확인 (V002)
   └─ V003 실행
   └─ 버전 기록 테이블 업데이트

┌─────────────────┬────────────────────┬────────────────────┐
│                 │ Flyway             │     Liquibase      │
├─────────────────┼────────────────────┼────────────────────┤
│마이그레이션 형식│ SQL 파일           │ XML/YAML/SQL       │
│ 버전 관리       │ 파일명 순서        │ changeset ID       │
│      롤백       │ 유료(Pro)          │ 무료 지원          │
│ DB 독립성       │ SQL이므로 DB 종속  │ 추상 형식이면 독립 │
│ 학습 곡선       │ 매우 낮음          │        보통        │
│ 잠금 관리       │        내장        │        내장        │
│ Spring Boot     │ 자동 설정          │ 자동 설정          │
│ 권장 상황       │ 단일 DB 프로젝트   │ 멀티 DB 지원 필요  │
└─────────────────┴────────────────────┴────────────────────┘

Flyway 명명 규칙:
V1__Create_users.sql    (버전 마이그레이션)
V2__Add_email.sql       (순서대로 실행)
R__Views.sql            (반복 실행 가능)

──── 1단계 배포 ────
ALTER TABLE users ADD COLUMN user_name VARCHAR(100);
UPDATE users SET user_name = name;
-- 코드: name과 user_name 두 컬럼 모두 쓰기

──── 2단계 배포 ────
-- 코드: user_name만 사용하도록 전환
-- 트리거: name에 쓰면 user_name에도 복사 (안전장치)

──── 3단계 배포 ────
ALTER TABLE users DROP COLUMN name;
-- 트리거 제거

┌─────────────────────────────────────────────────────────────┐
│                    계층별 권장 접근법                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Command (CUD)                                              │
│  ├─ 단순 CRUD → ORM 엔티티 (변경 감지 활용)                 │
│  ├─ 벌크 처리 → Native Query / JDBC Batch                   │
│  └─ 복잡한 비즈니스 → ORM + 도메인 로직                     │
│                                                             │
│  Query (R)                                                  │
│  ├─ 단순 조회 → ORM (Fetch Join)                            │
│  ├─ 복잡한 검색 → QueryDSL / Query Builder                  │
│  ├─ 통계/집계 → Native SQL                                  │
│  └─ 대시보드 → 전용 View 또는 Materialized View             │
│                                                             │
│  CQRS 패턴 적용 시:                                         │
│  ├─ Command 측: ORM (도메인 모델 중심)                      │
│  └─ Query 측: QueryDSL / Raw SQL (성능 중심)                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

────────────────────────────────────────────────
위험한 코드 (문자열 연결)
────────────────────────────────────────────────
// 절대 하면 안 됨!
String sql = "SELECT * FROM users WHERE name = '"
           + userInput + "'";
// userInput이 "'; DROP TABLE users; --" 이면 재앙

────────────────────────────────────────────────
안전한 코드 (파라미터 바인딩)
────────────────────────────────────────────────
// JPA
em.createNativeQuery(
  "SELECT * FROM users WHERE name = :name")
  .setParameter("name", userInput);

// JDBC PreparedStatement
PreparedStatement ps = conn.prepareStatement(
  "SELECT * FROM users WHERE name = ?");
ps.setString(1, userInput);

// Prisma (자동 이스케이프)
prisma.$queryRaw`SELECT * FROM users
  WHERE name = ${userInput}`;

핵심 원칙:
* 사용자 입력을 SQL 문자열에 직접 연결하지 않기
* 항상 파라미터 바인딩(Prepared Statement) 사용
* ORM이 생성하는 쿼리는 기본적으로 안전
* Raw SQL 작성 시 반드시 파라미터 바인딩 확인

프로젝트 시작
  │
  ├─ Java/Kotlin?
  │   ├─ 복잡한 도메인 → JPA/Hibernate + QueryDSL
  │   ├─ SQL 직접 제어 → MyBatis
  │   └─ 두 가지 혼합 → JPA(CUD) + MyBatis(R)
  │
  ├─ TypeScript/JavaScript?
  │   ├─ 타입 안전성 중시 → Prisma
  │   ├─ Active Record 선호 → TypeORM
  │   ├─ SQL 친화적 → Knex.js
  │   └─ 경량 프로젝트 → Sequelize
  │
  ├─ Python?
  │   ├─ Django 사용 → Django ORM
  │   ├─ 고급 제어 → SQLAlchemy (Core + ORM)
  │   └─ 비동기 필요 → SQLAlchemy 2.0 + asyncio
  │
  └─ 성능 최우선?
      └─ Query Builder 또는 Raw SQL 중심 설계

┌─────────────────────────────────────────────────────────────┐
│            ORM과 SQL 균형의 5가지 원칙                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. ORM을 기본으로, SQL을 무기로                            │
│     → CRUD는 ORM, 복잡한 조회는 SQL                         │
│                                                             │
│  2. 생성되는 SQL을 항상 확인하라                            │
│     → 쿼리 로그를 개발 중 항상 켜둘 것                      │
│                                                             │
│  3. N+1은 반드시 잡아라                                     │
│     → Fetch Join, BatchSize, DTO 조회 활용                  │
│                                                             │
│  4. 추상화를 맹신하지 마라                                  │
│     → ORM이 생성하는 SQL의 실행 계획 확인                   │
│     → 느린 쿼리는 Raw SQL로 대체                            │
│                                                             │
│  5. 마이그레이션은 코드로 관리하라                          │
│     → Flyway/Liquibase/Prisma Migrate 사용                  │
│     → 운영 DB 변경은 반드시 안전한 절차 준수                │
│                                                             │
└─────────────────────────────────────────────────────────────┘