특정 DB의 기능을 사용하여 비즈니스적인 문제를 풀지 않아야 한다.

[YehyeokBang]

상황

중복 데이터를 방지하기 위해 MySQL의 IGNORE 기능을 사용하여 구현한다.

사용자 id와 상품 id를 기록하는 찜 테이블이 있다고 가정한다.
한 사용자는 특정 상품에 대해 찜을 한 번만 할 수 있고,
이미 찜한 상품에 다시 요청이 들어오면 무시해야 한다.

-- MySQL
INSERT IGNORE INTO favorite (user_id, product_id) VALUES (1, 33);

내용

MySQL의 INSERT IGNORE와 같은 (DB의) 특정 기능을 비즈니스 로직의 핵심 부분으로 사용하는 것은 데이터베이스 이식성 측면에서 문제가 될 수 있다.

MySQL의 IGNORE 기능은 중복 키나 데이터 타입 변환 오류 등이 발생했을 때 오류를 무시하고 실행을 계속하게 해주는 기능이다. 그러나 이 기능은 다른 데이터베이스들에서 동일하게 제공되지 않는다는 것이 문제이다.

PostgreSQL : INSERT IGNORE 구문이 없다. 대신 INSERT ... ON CONFLICT DO NOTHING (UPSERT) 구문을 사용한다.
Oracle : IGNORE 옵션이 없고, 예외 처리나 다른 방식으로 구현해야 한다.
SQL Server : 마찬가지로 직접적인 IGNORE 기능은 없다.

추측

어차피 데이터베이스를 변경하면, 대부분의 코드도 변경이 필요하지 않을까?

• SQL은 표준을 따르지만, 모든 데이터베이스 벤더가 이를 완벽히 준수하지 않는 것으로 알고 있다.
• DBMS 간에 꽤 많은 차이가 있는 것 같은데, 어차피 데이터베이스를 바꾸는 상황에서는 연관된 부분도 다 변경될 수밖에 없지 않을까?
  • 이런 관점에서 특정 DB에서만 제공하는 기능을 사용하는 것이 큰 문제가 아닐 수도 있지 않을까?

현실적으로 이식성의 중요성이 얼마나 크다고 볼 수 있을까?

• 팀이나 회사의 비용 절감 정책으로 DB 변경이 필요한 상황이 생길 수 있을 것 같다.
  • 이 경우 벤더에 종속적인 기능을 많이 사용했다면 마이그레이션 비용이 커질 것 같다.
• 그러나 대부분의 프로젝트는 처음 선택한 DB를 계속 사용하는 경우가 많지 않을까?

반대로, 벤더 특화 기능의 성능적 이점을 간과할 수 있을까?

• 자주 호출되는 기능에서 쿼리 수를 줄일 수 있다면 성능 향상에 직접적인 도움이 될 것이다.
• 비교적 발생 확률이 낮은 이식성 문제를 고려하여 DB의 강력한 기능(제공하는 경우)을 활용하지 않는 것이 과연 합리적인가?
  • 특정 DB의 장점을 충분히 활용하지 못한다면 그 DB를 선택한 이유가 퇴색되지 않을까?

더 넓게 본다면, 제어하기 힘든 외부 의존성에 강하게 결합된 경우 유지보수가 어려울 수 있다는 소프트웨어 설계 원칙과 연결되는 것 같다.

[YehyeokBang]

어차피 데이터베이스를 변경하면, 대부분의 코드도 변경이 필요하지 않을까?

### 정리
핵심은 `변경 가능성`과 `변경 비용`을 함께 고려한다는 것 같다.

특정 DB 기능을 활용하되, 그 의존성을 격리시켜 관리함으로써
`어차피 다 바뀐다`는 상황을 `일부만 바뀐다`로 개선할 수 있을 것 같다.

SQL 표준(ANSI SQL)은 존재하지만,
실제로는 각 벤더마다 다양한 방식으로 확장하고 구현한다.

• MySQL의 LIMIT vs Oracle의 ROWNUM
• PostgreSQL의 RETURNING 절 vs SQL Server의 OUTPUT 절
• MySQL의 TINYINT, MEDIUMINT vs PostgreSQL의 타입 체계

계층 추상화

생각보다 다른 부분을 보고 있으면, 어차피 다 바뀐다는 생각이 드는 것 같다.
그러나 아래처럼 데이터 계층을 추상화하여 사용하는 곳에서는 변화가 없도록 만들 수 있을 것 같다.
즉, 변경 범위를 최소화 시키는 것이다.

// 간단한 Repository 인터페이스 예시
public interface FavoriteRepository {
    boolean addFavorite(long userId, long productId);
    // ...
}

// MySQL 구현체
public class MySqlFavoriteRepository implements FavoriteRepository {
    @Override
    public boolean addFavorite(long userId, long productId) {
        // INSERT IGNORE INTO favorite (user_id, product_id) VALUES (?, ?)
        // 영향받은 행 수 확인 로직 후 true false 반환
    }
}

// PostgreSQL 구현체
public class PostgresFavoriteRepository implements FavoriteRepository {
    @Override
    public boolean addFavorite(long userId, long productId) {
        // INSERT INTO favorite (user_id, product_id) VALUES (?, ?) ON CONFLICT DO NOTHING
        // 영향받은 행 수 확인 로직 후 true false 반환
    }
}

ORM, JPA

JPA를 예시로 들면, DB dialect가 자동으로 처리되며,
일반적으로 많이 사용되는 쿼리가 자동으로 생성된다.
설정 파일 변경으로도 쉽게 이 환경을 구성할 수 있다.

정말 많이 쓰이지만, JPA 사용에도 여러 트레이드 오프가 있다.

1. 복잡한 쿼리나 특수 기능은 여전히 네이티브 쿼리가 필요하다.
2. JPA에 최적화된 방식으로 엔티티와 관계를 설계하게 된다.
3. JPQL 같은 JPA 고유 기술에 의존하게 될 수 있다.

근데 JPA를 사용하고 JPA에 핏하게 구현된다면,
결국 DB 벤더 의존성에서 벗어나려다 ORM/JPA 의존성으로 갈아타는 형태가 될 것 같은데, 이는 괜찮을까?

JPA 의존성이 DB 벤더 의존성보다 추상화 수준이 높고, 표준화가 되어 있어서 더 리스크가 적을 것 같긴 하다.