이 질문을 스택 오버플로에서 검색하려고 시도했지만 이에 대한 질문을 찾을 수 없습니다.
나는 새롭고 Liquibase알고 싶어
- 왜
Liquibase? Liquibase프로젝트에서 정확히 언제 사용해야 합니까?
이것은 모든 데이터베이스 변경 사항 을 한곳에 보관하는 것이지만 SQL일부 저장소 시스템에서 간단한 파일 을 만들고 시간이 지남에 따라 계속 업데이트 하면 비슷한 작업을 수행 할 수 있습니다 .
답변
자체 관리 형 스키마 생성 파일과 Liquibase (또는 기타 스키마 마이그레이션 도구) 의 주요 차이점 은 후자가 스키마 변경 로그를 제공한다는 것입니다. 이것은 시간에 따른 스키마 변경 기록입니다. 이를 통해 데이터베이스 디자이너 는 스키마 변경 사항 을 지정할 수 있으며 필요에 따라 스키마를 프로그래밍 방식으로 업그레이드하거나 다운 그레이드 할 수 있습니다.
다음과 같은 다른 이점이 있습니다.
- 데이터베이스 공급 업체 독립성 (의심 스럽지만 시도)
- 자동화 된 문서
- 데이터베이스 스키마 차이
한 가지 대체 도구는 플라이 웨이 입니다.
데이터 손실없이 스키마 업데이트를 자동으로 관리하고 싶거나 필요할 때 스키마 마이그레이션 도구를 사용하도록 선택할 수 있습니다. 즉, 시스템이 고객 사이트 또는 안정적인 테스트 환경과 같이 수명이 긴 환경에 배포 된 후 스키마가 변경 될 것으로 예상합니다.
답변
스키마를 수정할 때 개발자들 사이에서 liquibase가 규율을 만드는 것을 보았습니다. 다른 개발자의 변경 사항을 덮어 쓰고 실행할 수는 없습니다. 대신 고유 한 변경 집합을 만들어 실행할 변경 시퀀스의 끝에 추가합니다. 이것은 또한 어떤 변화가 언제 왔고 누가 가져 왔는지에 대한 명확성을 제공합니다.
스키마 유지 관리에 대한 매우 “버전 화 된”접근 방식입니다.
처음에는 “불필요한 작업”이라는 인상을줍니다.
답변
dev, qa, production에 여러 데이터베이스 인스턴스가 있고 변경 내역을 자동으로 추적하고 변경 사항을 지능적으로 적용하는 도구 (현재 스키마 및 최종 스키마의 차이 적용)를 원할 때 liquibase 또는 flyway와 같은 도구가 매우 유용합니다. .
답변
나는 당신의 철학이 데이터베이스가 사후에 고려 될 때 Liquibase가 훌륭하다고 믿습니다. 이 철학은 프로덕션에서 대부분의 불량 데이터베이스를 유발했으며 대부분은 불량입니다. 데이터베이스는 각각의 사일로에서 작업하는 애플리케이션 개발자가 구성하지 않고 전체 비즈니스 시스템을 전체적으로 볼 수 있도록 설계해야합니다. 후자의 방법은 해결 방법, 비정규 화 된 데이터, 테이블 간의 열악한 관계, 비즈니스 영역의 중복 및 전체적으로 지저분하고 유지 관리 비용이 많이 드는 시스템을 초래하여 클라이언트가 발생하는 문제로 인해 배포 직후 싫어할 것입니다. 데이터베이스가 비즈니스 관계를 정확하게 반영하도록 설계된 경우 수명은 5 배 길고, 불행히도 대부분의 단편적인 방식으로 설계된 데이터베이스보다 5 배 더 나은 목적을 달성 할 것입니다.
Liquibase는 그 자체로는 문제가되지 않지만 응용 프로그램 개발자가 데이터베이스를 설계 할 수 있도록합니다. 그게 문제 야.
답변
아래 기사 http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html을 통해 왜 liquibase에 대한 답을 얻을 수 있을까요?
주의 깊게 읽으면 간단한 mvn 또는 CLI 명령을 사용하여 상위 버전에서 하위 버전으로 다운 그레이드하는 기능이 매우 유용합니다. 수동으로 해당 스크립트를 실행해야하며 다음과 같은 변경 설정도 없습니다.
답변
내 팀의 DevOps 사람이기 때문에 모든 SQL 파일을 한곳에두고 싶습니다. 즉, SCM (소스 코드 관리)에서
또한 CI / CD 단계에서 DB Schema가 함께 생성되면 많은 시간과 자원을 절약 할 수 있습니다. 해당 클라이언트의 데이터베이스를 관리하는 다른 사람이 필요하지 않습니다.
Flyway, Liquibase, EF 등과 같은 ORM은이를 달성하는 데 도움이됩니다.
답변
