確認問題：新旧スキーマの共存と安全な縮小

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

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

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

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

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

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

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

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

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

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

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

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