DB 스키마 변경 계획기
두 SQL 텍스트의 글자 차이가 아니라 작은 PostgreSQL 16 스키마의 객체 차이를 비교합니다. 엄격한 로컬 파서가 테이블·열·단일 열 명명 외래 키·기본 키·단순 인덱스를 모델링하고 의존성 해제·이름 변경·추가·제약 순서를 만듭니다. 사라진 이름과 새 이름은 명시적 매핑 또는 별도 삭제/추가 확인 전까지 모호합니다. 데이터 손실과 검증 위험 단계는 개별 확인이 필요하고 지원하지 않는 변경은 SQL 출력을 막습니다. 실제 DB·행·뷰·권한·운영 잠금은 조회하지 않습니다.
주요 기능
- PostgreSQL 16 제한 DDL을 끝까지 검사하고 지원하지 않는 구문은 거부
- 명시적 테이블·열 이름 변경과 미해결 이름의 모호성 표시
- 테이블·열·인덱스·외래 키의 의존성 순서와 변경 이유
- 고위험 단계별 확인과 수동 변경 차단 후 SQL 출력
- 로컬 JSON 검토 기록과 확인 후 PostgreSQL SQL 저장
사용 방법
- 전후 CREATE TABLE/INDEX 문을 붙여넣거나 로컬 SQL 파일을 엽니다.
- 예제를 보며 이름 변경을 old -> new로 명시하고, 남은 이름이 실제 별도 삭제·추가인지 검토합니다.
- 순서·의존성·삭제 위험·수동 차단 사항을 확인합니다.
- 고위험 단계를 각각 확인해 검토용 SQL을 연 뒤 백업과 실제 DB 상태를 대조합니다.
활용 예시
- 기존 열 값을 지우지 않고 이름 변경을 계획
- 기준 테이블을 지우기 전에 외래 키가 제거되는지 확인
- 고유 인덱스·새 외래 키의 기존 데이터 검증 위험 찾기
- 자료형 변경·새 필수 열의 수동 보정 필요성을 표시
자주 묻는 질문
어떤 SQL 방언과 문장을 지원하나요?
제한된 PostgreSQL 16 범위만 지원합니다. 따옴표 없는 단순 식별자, 지원 자료형과 선택적 NOT NULL의 CREATE TABLE, 테이블 기본 키, 이름 있는 단일 열 외래 키, 단순 CREATE [UNIQUE] INDEX입니다. 그 외 구문은 전체 입력을 거부합니다.
이름 변경을 자동 추정하나요?
아니요. 사라진 이름과 새 이름은 변경일 수도 별도 삭제·추가일 수도 있습니다. 테이블·열 변경을 명시하거나 별도 작업임을 확인해야 하며 위험한 삭제 단계도 각각 확인해야 합니다.
이 SQL을 운영 DB에서 그대로 실행해도 안전한가요?
자동 실행은 하지 않습니다. BEGIN/COMMIT과 RESTRICT를 쓰지만 실제 행·외부 뷰/함수·잠금·권한·백업·복구 경로는 모릅니다. 백업 환경에서 시험하고 DB 담당자가 검토해야 합니다.
자료형 변경이나 새 NOT NULL 열은 왜 차단되나요?
USING 식이나 기존 행 값 보정이 필요할 수 있고 실제 데이터에서 실패할 수 있습니다. 도구는 변환식이나 기본값을 임의로 만들지 않습니다.
외래 키와 인덱스는 순서에 반영하나요?
모델에 있는 오래된 외래 키·인덱스를 먼저 제거하고 새 테이블을 만든 뒤 새 제약을 마지막에 추가합니다. 모델 밖 의존 객체에서는 RESTRICT가 중지될 수 있습니다.
개인정보 안내
DDL과 매핑은 이 브라우저에서만 해석합니다. DB에 연결하거나 앱 API에 스키마를 보내지 않으며 파일 저장은 로컬에서 처리합니다.
댓글과 질문