Tôi đã cố gắng tìm kiếm câu hỏi này trên ngăn xếp tràn nhưng không thể tìm thấy bất kỳ câu hỏi nào cho điều này.
Tôi là người mới Liquibasevà muốn biết
Liquibase?Liquibasetrong dự án?Tôi biết rằng điều này là để giữ tất cả các thay đổi cơ sở dữ liệu ở một nơi nhưng điều tương tự có thể được thực hiện bằng cách tạo một SQLtệp đơn giản trong một số hệ thống kho lưu trữ và liên tục cập nhật nó theo thời gian.
Câu trả lời:
Điểm khác biệt chính giữa tệp tạo lược đồ tự quản lý và Liquibase (hoặc các công cụ di chuyển lược đồ khác ) là cái sau cung cấp một thay đổi lược đồ. Đây là bản ghi về những thay đổi của lược đồ theo thời gian. Nó cho phép nhà thiết kế cơ sở dữ liệu chỉ định các thay đổi trong lược đồ và cho phép nâng cấp hoặc hạ cấp lược đồ theo lập trình theo yêu cầu.
Có những lợi ích khác, chẳng hạn như:
Một công cụ thay thế là đường bay .
Bạn sẽ chọn sử dụng công cụ di chuyển giản đồ khi bạn muốn hoặc cần tự động quản lý các bản cập nhật giản đồ mà không làm mất dữ liệu. Có nghĩa là, bạn mong đợi lược đồ thay đổi sau khi hệ thống của bạn đã được triển khai đến một môi trường tồn tại lâu dài như trang web của khách hàng hoặc môi trường thử nghiệm ổn định.
Tôi đã thấy liquibase tạo ra kỷ luật giữa các nhà phát triển khi nói đến việc sửa đổi lược đồ. Bạn chỉ không thể ghi đè thay đổi của nhà phát triển khác và thực thi. Thay vào đó, bạn tạo tập thay đổi của riêng mình và thêm tập hợp đó vào cuối chuỗi thay đổi sẽ được thực thi. Điều này cũng mang lại sự rõ ràng về sự thay đổi đã đến khi nào và ai đã mang đến nó.
Một cách tiếp cận rất "có phiên bản" để bảo trì lược đồ.
Đối với những người mới bắt đầu, nó thực sự tạo ấn tượng về "công việc không cần thiết".
Khi bạn có nhiều trường hợp cơ sở dữ liệu trong dev, qa, production và bạn muốn có một công cụ để tự động theo dõi lịch sử thay đổi và áp dụng các thay đổi một cách thông minh (áp dụng sự khác biệt của giản đồ hiện tại và giản đồ cuối cùng), các công cụ như liquibase hoặc flyway sẽ rất hữu ích .
Tôi tin rằng Liquibase là tuyệt vời khi triết lý của bạn là cơ sở dữ liệu là một suy nghĩ sau. Triết lý này đã gây ra phần lớn các cơ sở dữ liệu xấu trong quá trình sản xuất - và hầu hết chúng đều xấu. Một cơ sở dữ liệu nên được thiết kế với cái nhìn đầy đủ về toàn bộ hệ thống kinh doanh, chứ không phải do các nhà phát triển ứng dụng chắp vá, mỗi người làm việc trong silo riêng của họ. Phương pháp thứ hai dẫn đến giải pháp thay thế, dữ liệu không chuẩn hóa, mối quan hệ kém giữa các bảng, trùng lặp các khu vực kinh doanh và một hệ thống tổng thể lộn xộn, chi phí bảo trì cao mà khách hàng sẽ ghét ngay sau khi triển khai do các vấn đề mà nó gây ra. Nếu một cơ sở dữ liệu được thiết kế để phản ánh CHÍNH XÁC các mối quan hệ kinh doanh, tuổi thọ của nó sẽ dài gấp 5 lần và sẽ phục vụ mục đích của nó tốt hơn gấp 5 lần so với một cơ sở dữ liệu được thiết kế theo kiểu chắp vá như hầu hết.
Bản thân Liquibase không phải là một vấn đề nhưng nó cho phép các nhà phát triển ứng dụng thiết kế cơ sở dữ liệu. Đó là vấn đề.
Tôi nghĩ Tại sao liquibase có thể được giải đáp nếu bạn xem qua bài viết dưới đây http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html
Nếu bạn đọc kỹ, khả năng hạ cấp xuống phiên bản thấp hơn từ phiên bản cao hơn với sự trợ giúp của các lệnh mvn hoặc CLI đơn giản là rất hữu ích mà bạn sẽ không nhận được nếu bạn thực hiện phương pháp chuyển tệp sql của mình vào GIT vì khi đó bạn phải chạy các tập lệnh đó theo cách thủ công và bạn cũng không có bộ thay đổi như: - ai đã thay đổi tác giả, v.v.
Là DevOps Person trong nhóm của tôi, tôi muốn có tất cả các tệp SQL của mình ở một nơi, tức là Trong SCM của tôi (Quản lý mã nguồn)
Cũng trong thời gian CI giai đoạn / CD, Nếu lược đồ DB được tạo cùng với nó, nó sẽ tiết kiệm rất nhiều thời gian và tài nguyên. Bạn sẽ không cần phải có người khác quản lý cơ sở dữ liệu của mình cho khách hàng đó.
ORM như Flyway, Liquibase, EF, v.v. giúp Đạt được điều này.