9장 - 갱신과 데이터 모델

NULL 값 다루기

만약 테이블에 존재하는 NULL 값이 특정 규칙을 갖는다면, 반복계를 사용하여 NULL 값을 채우는 것보다 집합계를 사용하는 것이 더 좋다.

다중 필드 사용하기

update ScoreCols
  set score_en = (select score
                  from ScoreRows SR
                  where SR.student_id = ScoreCols.student_id
                    and subject = '영어'),
      score_nl = (select score
                  from ScoreRows SR
                  where SR.student_id = ScoreCols.student_id
                    and subject = '국어'),
      score_mt = (select score
                  from ScoreRows SR
                  where SR.student_id = ScoreCols.student_id
                    and subject = '수학');

위 쿼리는 한 과목씩 갱신하므로 서브쿼리가 3번 실행된다.

이럴 때 다음과 같이 다중 필드 할당을 사용하면 서브쿼리를 한꺼번에 처리할 수 있다.

update ScoreCols
  set (score_en, score_nl, score_mt)
    = (select max(case when subject = '영어'
                       then score
                       else null end) score_en,
              max(case when subject = '국어'
                       then score
                       else null end) score_nl,
              max(case when subject = '수학'
                       then score
                       else null end) score_mt
       from ScoreRows SR
       where SR.student_id = ScoreCols.student_id);

INSERT가 UPDATE보다 더 좋을까?

UPDATE로 원래 테이블을 수정하는 대신, INSERT를 사용해서 새로운 테이블을 만든다고 가정해보자.

일반적으로 UPDATE보다 INSERT의 성능이 더 좋지만 같은 크기와 구조를 가진 데이터를 두 개 만들어야 한다.

하지만 최근 저장소 가격이 낮아진 것을 생각하면 큰 단점은 아닌 거 같다.

 

만약 새로운 테이블을 만드는 대신 VIEW를 생성하는 건 어떨까?

저장소 용량을 절약할 수 있을 뿐더러, 항상 최신 정보를 유지할 수 있다.

그러나 뷰에 접근할 때마다 복잡한 쿼리가 수행되므로 성능이 낮아진다.

따라서 성능과 동기성 사이의 트레이드오프를 잘 고려해야 한다.

결합 vs 모델 갱신

특정 데이터가 필요할 때 두 개 이상의 테이블을 결합하여 반환하는 게 좋을까?

아니면 테이블 스키마를 수정하여 필요한 정보를 플래그 형태 등으로 저장하는 게 좋을까?

 

일단 첫 번째 방법의 경우 검색할 때 결합 또는 집약을 포함한 SQL 구문을 사용하므로 비용이 높아지고, 성능을 불안정하게 만든다.

모델 갱신의 트레이드오프

<갱신 비용>

첫 번째 방법과 달리 검색 부하를 갱신 부하로 바꾸는 꼴이다.

 

<갱신까지의 시간 랙(Time Rag) 발생>

데이터의 실시간성 때문에 테이블 간에 데이터가 동기화되지 않은 경우 상태 차이가 발생할 수 있다.

따라서 갱신의 간격을 짧게 하거나, 동일 트랜잭션으로 처리해야 한다.

하지만 성능과 실시간성 사이에 심각한 트레이드오프가 발생한다.

 

<모델 갱신비용 발생>

프로젝트 막바지에 모델을 변경하는 것은 시스템 품질과 개발 일정 모두에 큰 리스크가 될 수 있다.

결론

데이터 모델 차원에서의 대응이 단순하면서도 최적의 솔루션이 되는 경우가 꽤 많다.

하지만 무엇보다도 가장 좋은 것은 시작부터 데이터 모델 설계를 잘 하는 것이다.