Di chuyển lược đồ: Công cụ dữ liệu SQL Server so với Liquibase và Flyway

Điều này có vẻ như là một câu hỏi ngu ngốc, nhưng tôi đã xem xét các giải pháp nguồn mở để di chuyển lược đồ, cụ thể là Liquibase và Flyway.

Tuy nhiên, ông chủ của tôi nói với tôi rằng Công cụ dữ liệu SQL Server (SSDT) ​​đạt được công việc tương tự. Tôi không chắc là có đồng ý hay không, nhưng tôi có thể tìm thấy rất ít trên Internet so sánh trực tiếp nó với Liquibase và / hoặc Flyway.

Quan điểm của tôi là SSDT là một công cụ phát triển, mô hình hóa và thiết kế dữ liệu cho SQL Server và cũng hỗ trợ so sánh lược đồ (và tạo các tập lệnh của chúng) và kiểm soát nguồn. Nó giải quyết một vấn đề khác mặc dù có thể có một số trùng lặp với Liquibase / Flyway trong một số khía cạnh của việc di chuyển lược đồ. Nhưng với tư cách là một công cụ di chuyển lược đồ tổng thể, Liquibase và Flyway là các công cụ dành riêng hoàn toàn trong khi SSDT dành cho thiết kế và phát triển cơ sở dữ liệu.

Mọi ý kiến ​​sẽ được đánh giá cao ngay cả khi chỉ nói rằng không có so sánh và SSDT hoàn toàn không phải là một công cụ di chuyển lược đồ.

SSDT có thể so sánh với Liquibase / Flyway vì nó làm những gì họ làm nhưng bằng cách thực hiện một cách tiếp cận khác. Với SSDT, bạn có môi trường phát triển để bạn có được những thứ như định nghĩa, tìm tài liệu tham khảo và ý nghĩa nội bộ cũng như khả năng biên dịch dự án thành dacpac và sau đó triển khai dacpac đó vào cơ sở dữ liệu.

Cách SSDT (và sắp xếp lại cách so sánh sql) để thực hiện một sự phân chia là khai báo những gì bạn muốn vì vậy nếu bạn muốn thay đổi một bảng trông giống như:

create table a(id int)

đến một bảng trông giống như:

create table a(id int, another_column varchar(12))

với SSDT, bạn chỉ cần thay đổi định nghĩa bảng của mình sang bảng thứ hai và để SSDT lo lắng về cách nâng cấp nó (có thể thay đổi bảng, thêm cột hoặc thay đổi thứ tự cột để bạn cần xây dựng lại bảng, v.v.).

Với Liquibase (DbUp, ReadyRoll, phương thức thủ công, v.v.) những gì bạn làm là trong trường hợp này phải tự viết bảng thay đổi và đảm bảo rằng bạn chạy các tập lệnh theo đúng thứ tự, hãy xem xét kịch bản này:

1. Phát hành 1 - tạo cột xin chào trên bàn
2. Phát hành 2 - đổi tên cột xin chào thành joe_bloss
3. Phát hành 3 - đổi tên cột joe_bloss để chào
4. Phát hành 4 - tạo cột joe_bloss

Nếu bất kỳ bản phát hành nào bị bỏ lỡ, không có bản nào tiếp theo có thể tiếp tục.

Lợi ích của các tập lệnh nâng cấp (Liquibase, DbUp, v.v.):

• Bạn có toàn quyền kiểm soát các tập lệnh
• DBA's / Developers đã quen với điều này

Lợi ích của việc so sánh / hợp nhất (SSDT, Redgate SQL So sánh):

• Không phải viết kịch bản nâng cấp
• Thật dễ dàng để đến bất kỳ phiên bản cụ thể nào, chỉ cần so sánh và hợp nhất phiên bản đó

Hạn chế của các kịch bản nâng cấp:

• Phải được chạy theo thứ tự
• Dựa vào con người không phạm sai lầm
• Có thể chậm đặc biệt là nếu bạn có nhiều thay đổi
• Trừ khi nhóm của bạn là các cơ sở dữ liệu rất kỷ luật trong các môi trường khác nhau (dev, test, staging, prod, v.v.) thường không đồng bộ hóa khiến mọi thử nghiệm không hợp lệ
• Hạ cấp một bản phát hành có nghĩa là viết ngược lại tất cả các tập lệnh bạn đã viết

Hạn chế của việc sử dụng so sánh / hợp nhất:

• Công cụ không đáng tin cậy 100%, có lẽ không công bằng
• SSDT yêu cầu một dự án làm việc, nhiều cơ sở dữ liệu có mã không thực sự biên dịch hoặc chạy (nghĩ rằng các bảng bị rớt nhưng không làm thủ tục, v.v.), tôi đã thấy điều này trong khoảng 8/10 cơ sở dữ liệu tôi đã kế thừa :)
• Nhiều nhà phát triển / nhà phát triển của DBA ngần ngại từ bỏ việc phát triển trong SSMS / notepad

Cá nhân tôi thực sự nghĩ rằng SSDT là một môi trường phát triển chuyên nghiệp và điều đó có nghĩa là tôi có thể tập trung vào việc viết mã và kiểm tra hữu ích thay vì viết các kịch bản nâng cấp mà bản thân chúng chỉ là phương tiện để kết thúc.

Bạn hỏi ý kiến ​​để bạn đi :)

ed

Tôi chỉ cần trả lời từ trên xuống.

Sự khác biệt lớn nhất được mô tả trên trang web Flyway ở vị trí trung tâm:

Chỉ giải quyết một vấn đề và giải quyết nó tốt. Flyway di chuyển cơ sở dữ liệu của bạn, vì vậy bạn không phải lo lắng về nó nữa.

Visual Studio + SSDT + SSIS = Công cụ ETL toàn năng, chỉ có một nhược điểm thực sự - nó chỉ hoạt động dưới cửa sổ Nó cần Windows + SQL Server để chạy các gói, nhưng hoạt động với hầu hết tất cả các nguồn.

Để chuyển / di chuyển dữ liệu - rất nhiều sản phẩm trên thị trường. Thương mại, nguồn mở, cộng đồng / Express và vv

Đối với mã di chuyển - tất cả không tốt. Ngay cả khi phần mềm hứa hẹn "chuyển đổi trình kích hoạt, quy trình và chức năng mà không gặp sự cố", trên thực tế - chỉ đơn giản, hầu hết di chuyển mã - thủ công.

Tôi đã làm việc với cả công cụ dữ liệu máy chủ và đường bay. Sử dụng SSDT, tôi nhận được những lợi thế sau:

1. Tôi có thể biên dịch dự án cơ sở dữ liệu .. có nghĩa là, không sợ bỏ một cột đang được tham chiếu bởi một khung nhìn, hàm hoặc các procs được lưu trữ. Đây là một tính năng tuyệt vời, bởi vì trong quá khứ, chúng tôi đã tìm thấy những lỗi như vậy chỉ sau khi phát hành

2. Sau khi xây dựng thành công, SSDT tạo ra cái được gọi là "DACPAC". Hãy nghĩ về điều này một msi với một phiên bản.

3. Một dacpac đã cho, với phiên bản 5, có thể được áp dụng cho cơ sở dữ liệu trên phiên bản Dacpac 1,2,3,4 hoặc 6,7,8, v.v ... Nếu áp dụng cho 1-4, cơ sở dữ liệu sẽ được nâng cấp. Nếu áp dụng cho 6,7, v.v., DB sẽ bị hạ cấp / khôi phục. Sẽ có cảnh báo, nếu có mất dữ liệu, có thể bị triệt tiêu. Vì vậy, chúng tôi nhận được một tính năng rollback tuyệt vời, không có sẵn với các công cụ khác như flyway, v.v ... Với flyway, người ta phải cung cấp một tập các kịch bản mới để khôi phục.

4. DACPAC áp dụng tất cả các thay đổi trong một giao dịch; có nghĩa là nếu có 5 thay đổi bảng trong nâng cấp và một trong số đó không thành công, toàn bộ giao dịch sẽ được khôi phục. Flyway cũng hỗ trợ điều này, nhưng đối với mọi tệp.

Tuy nhiên, SSDT và DACPAC là Microsoft SQL Server cụ thể; đường bay có thể được sử dụng cho một loạt các cơ sở dữ liệu.

Vì vậy, điểm mấu chốt, nếu bạn chỉ sử dụng SQL Server, đó là một quyết định khá dễ dàng với SSDT và DACPAC.