퀴즈: 구·신 스키마 공존과 안전한 축소

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. 새 display_name이 모두 채워졌다. COALESCE(display_name,name)을 읽는 전환용 앱이 남아 있다면?

   1. NULL이 없으므로 name 열은 실행되지 않아 바로 제거해도 된다.
   2. name을 참조하지 않는 최종 앱으로 옮기고 전환용 앱 퇴역도 확인해야 한다.
   3. name에 빈 문자열을 넣으면 참조가 없어져 제거해도 된다.
   4. 새 열에 NOT NULL을 선언하면 전환용 SQL이 자동으로 바뀐다.

2. 새 열의 CHECK를 NOT VALID로 추가했다. 이때 정확한 설명은?

   1. 새 쓰기와 기존 행을 모두 검사하지 않고 제약 이름만 저장한다.
   2. 기존 행을 모두 검사하지만 새 쓰기는 VALIDATE 전까지 허용한다.
   3. 기존 NULL 행을 자동 삭제해 새 쓰기 조건에 맞춘다.
   4. 기존 행의 전체 검사는 미루지만 새 쓰기에는 조건을 적용한다.

3. 백필 앱이 먼저 읽은 옛 이름을 저장해 뒀다가 다른 담당자의 변경 뒤 UPDATE한다. 주된 위험은?

   1. 후속 변경을 과거 값으로 덮을 수 있어 현재 행 조건과 값을 DB에서 함께 평가해야 한다.
   2. SELECT는 읽기라서 이후 UPDATE의 값도 항상 최신으로 유지된다.
   3. 백필하는 ID 수가 같다면 다른 담당자의 이름 변경도 보존된다.
   4. UPDATE를 재시도할 때마다 같은 옛 값을 쓰면 동시성 문제가 해결된다.

4. 양방향 호환 트리거에서 한 UPDATE가 name과 display_name을 서로 다른 새 값으로 바꿨다. 이번 계약은?

   1. 옛 앱 호환이 중요하므로 name을 항상 정답으로 삼는다.
   2. 최신 앱의 열 이름이므로 display_name을 무조건 정답으로 삼는다.
   3. 입력의 의미가 모순되므로 거절하고 자동으로 한쪽을 선택하지 않는다.
   4. 두 값을 이어 붙여 새 열에 넣고 기존 값도 함께 보존한다.

5. 호환 트리거를 지운 뒤 옛 열 제거 전에 클라이언트가 종료됐다. 요구한 축소 원자성은?

   1. 트리거가 이미 삭제됐으므로 남은 열도 다음 부팅에서 강제로 지운다.
   2. 커밋 전이면 트리거·함수·열 변경 전체가 롤백돼 호환 경로가 살아 있다.
   3. 옛 열만 남으면 데이터가 있으므로 트리거 부재는 무시할 수 있다.
   4. 오류 응답이 없었으므로 이미 축소된 것으로 기록하고 재시작하지 않는다.

6. DB의 새 열은 NOT NULL이고 퇴역 플래그도 True다. 이것만으로 운영의 옛 소비자 부재가 증명되는가?

   1. 제약이 유효하므로 옛 SQL을 읽는 프로그램도 모두 종료됐다고 볼 수 있다.
   2. 최근 오류가 없으면 재시도 큐와 예약 작업은 확인하지 않아도 된다.
   3. 스키마 이름을 확인했으면 외부 분석 도구는 소비자 목록에서 제외한다.
   4. 아니다. 실행 버전·예약 작업·재시도·직접 조회 도구 등의 별도 근거가 필요하다.