새 테이블을 추가하고 다른 테이블을 변경하는 등 개발 중에 데이터베이스 스키마를 많이 변경했습니다. 구현하는 데 약 15시간이 걸렸던 모든 변경 사항을 반복하지 않고도 이 스키마를 서버로 전송하고, 새 테이블을 구축하고, 다른 테이블을 재구축할 수 있는 쉬운 방법이 있습니까?
답변1
물론이죠. 하지만 미리 계획을 세우면 더 쉽게 할 수 있습니다.
다양성
sql데이터베이스 마이그레이션(스키마 변경 등)을 생성할 때 변경 사항을 캡슐화하는 문을 생성해야 합니다 . 데이터가 포함된 기존 테이블에 열을 추가하는 경우 sql변경 내용을 설명하는 문을 생성할 수 있어야 합니다 . 예를 들어:
ALTER TABLE `myTable`.`local`
ADD COLUMN `last_update` timestamp NULL AFTER `location_name`,
...;
각 변경 사항을 추적하는 명령문이 포함된 파일 을 보관한 sql다음 프로덕션 테이블에서 해당 명령문을 올바른 순서로 실행하면 문제가 없을 것입니다. 추적하는 경우 이러한 유형의 콘텐츠를 버전 제어에 추가할 수도 있습니다. 이는 이미 이러한 지원을 제공하는 프레임워크의 도움 없이 이를 수행하는 가장 좋은 방법일 것입니다.
새 테이블
새로운 것이 더 쉽습니다. 모든 인덱스와 데이터 유형을 파악할 때까지 계속 작업한 다음 스키마를 파일에 덤프합니다 .sql. 프로덕션 서버에서 이 명령을 실행하면 테이블이 거기에 있어야 합니다.
mysqldump -d -h localhost -u root -pmypassword databasename > dumpfile.sql
-d데이터가 아닌 스키마만 덤프되어야 합니다 .
힘든 길
증분 변경 사항의 실행 목록을 유지하지 않거나 스키마를 크게 변경하지 않으면 조금 더 어렵습니다. 프로덕션 테이블과 개발 테이블의 스키마를 수동으로 비교하고 마이그레이션을 수동으로 생성해야 할 수도 있습니다. 기존 데이터가 더 이상 필드 정의에 맞지 않을 정도로 테이블을 너무 많이 변경하지 않았다고 가정합니다.
프로덕션 테이블에서 스키마를 덤프하고 이를 개발 시스템의 다른 데이터베이스로 가져온 다음 거기에서 마이그레이션을 생성할 수 있습니다. 그러나 이전 스키마에서 새 스키마로의 마이그레이션만 생성하면 되므로 새 스키마를 설계하는 것보다 속도가 더 빠를 수 있다는 점을 명심하세요.