Có hệ thống kiểm soát phiên bản cho các thay đổi cấu trúc cơ sở dữ liệu không?

Tôi thường gặp phải vấn đề sau đây.

Tôi thực hiện một số thay đổi đối với một dự án yêu cầu bảng hoặc cột mới trong cơ sở dữ liệu. Tôi thực hiện sửa đổi cơ sở dữ liệu và tiếp tục công việc của mình. Thông thường, tôi nhớ ghi lại các thay đổi để chúng có thể được nhân rộng trên hệ thống trực tiếp. Tuy nhiên, không phải lúc nào tôi cũng nhớ mình đã thay đổi những gì và không phải lúc nào tôi cũng nhớ viết ra giấy.

Vì vậy, tôi thực hiện một lần đẩy hệ thống trực tiếp và nhận được một lỗi lớn, rõ ràng là không có NewColumnX, ugh.

Bất kể thực tế là đây có thể không phải là cách tốt nhất cho tình huống này, có hệ thống kiểm soát phiên bản cho cơ sở dữ liệu không? Tôi không quan tâm đến công nghệ cơ sở dữ liệu cụ thể. Tôi chỉ muốn biết nếu một cái tồn tại. Nếu nó hoạt động với MS SQL Server, thì thật tuyệt.

Trong Ruby on Rails, có một khái niệm về sự di chuyển - một tập lệnh nhanh chóng để thay đổi cơ sở dữ liệu.

Bạn tạo tệp di chuyển, tệp này có các quy tắc để tăng phiên bản db (chẳng hạn như thêm một cột) và các quy tắc để hạ cấp phiên bản (chẳng hạn như xóa một cột). Mỗi lần di chuyển được đánh số và một bảng theo dõi phiên bản db hiện tại của bạn.

Để di chuyển lên , bạn chạy lệnh có tên "db: migrate" để xem phiên bản của bạn và áp dụng các tập lệnh cần thiết. Bạn có thể di chuyển xuống theo cách tương tự.

Bản thân các tập lệnh di chuyển được lưu giữ trong hệ thống kiểm soát phiên bản - bất cứ khi nào bạn thay đổi cơ sở dữ liệu, bạn sẽ kiểm tra tập lệnh mới và bất kỳ nhà phát triển nào cũng có thể áp dụng nó để đưa db cục bộ của họ lên phiên bản mới nhất.

Tôi hơi cũ, ở chỗ tôi sử dụng các tệp nguồn để tạo cơ sở dữ liệu. Thực tế có 2 tệp - dự án-database.sql và dự án-Updates.sql - tệp đầu tiên dành cho lược đồ và dữ liệu liên tục, tệp thứ hai dành cho các sửa đổi. Tất nhiên, cả hai đều được kiểm soát nguồn.

Khi cơ sở dữ liệu thay đổi, trước tiên tôi cập nhật lược đồ chính trong project-database.sql, sau đó sao chép thông tin liên quan vào project-Updates.sql, chẳng hạn như câu lệnh ALTER TABLE. Sau đó, tôi có thể áp dụng các bản cập nhật cho cơ sở dữ liệu phát triển, kiểm tra, lặp lại cho đến khi hoàn thành tốt. Sau đó, kiểm tra tệp, kiểm tra lại và áp dụng cho sản xuất.

Ngoài ra, tôi thường có một bảng trong db - Config - chẳng hạn như:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Sau đó, tôi thêm phần sau vào phần cập nhật:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Điều db_versionduy nhất được thay đổi khi cơ sở dữ liệu được tạo lại và db_revisioncho tôi một dấu hiệu cho thấy db nằm ngoài đường cơ sở bao xa.

Tôi có thể giữ các bản cập nhật trong các tệp riêng biệt của riêng chúng, nhưng tôi đã chọn trộn tất cả chúng lại với nhau và sử dụng cắt & dán để trích xuất các phần có liên quan. Theo thứ tự, bạn cần phải dọn dẹp nhiều hơn một chút, tức là xóa ':' khỏi $ Revision 1.1 $ để đóng băng chúng.

MyBatis (trước đây là iBatis) có một công cụ di chuyển lược đồ , để sử dụng trên dòng lệnh. Nó được viết bằng java mặc dù có thể được sử dụng với bất kỳ dự án nào.

Để đạt được thực hành quản lý thay đổi cơ sở dữ liệu tốt, chúng ta cần xác định một vài mục tiêu chính. Do đó, Hệ thống di chuyển lược đồ MyBatis (hay gọi tắt là MyBatis Migrations) tìm cách:

• Làm việc với bất kỳ cơ sở dữ liệu nào, mới hoặc hiện có
• Tận dụng hệ thống kiểm soát nguồn (ví dụ: Subversion)
• Cho phép các nhà phát triển hoặc nhóm đồng thời làm việc độc lập
• Cho phép xung đột rất rõ ràng và dễ quản lý
• Cho phép di chuyển tới và lùi (tiến hóa, phát triển tương ứng)
• Làm cho trạng thái hiện tại của cơ sở dữ liệu dễ dàng truy cập và dễ hiểu
• Cho phép di chuyển bất chấp đặc quyền truy cập hoặc bộ máy hành chính
• Làm việc với bất kỳ phương pháp luận nào
• Khuyến khích các thực hành tốt, nhất quán

Redgate có một sản phẩm gọi là SQL Source Control . Nó tích hợp với TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce và Git.

Tôi thực sự khuyên bạn nên sử dụng SQL delta . Tôi chỉ sử dụng nó để tạo các tập lệnh khác khi tôi mã hóa xong tính năng của mình và kiểm tra các tập lệnh đó vào công cụ kiểm soát nguồn của tôi (Mercurial :))

Họ có cả máy chủ SQL và phiên bản Oracle.

Tôi tự hỏi rằng không ai đề cập đến công cụ mã nguồn mở liquibase dựa trên Java và sẽ hoạt động cho gần như mọi cơ sở dữ liệu hỗ trợ jdbc. So với đường ray, nó sử dụng xml thay vì ruby ​​để thực hiện các thay đổi lược đồ. Mặc dù tôi không thích xml cho các ngôn ngữ cụ thể của miền, nhưng lợi thế rất thú vị của xml là liquibase biết cách khôi phục một số hoạt động như

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Vì vậy, bạn không cần phải xử lý việc này của riêng mình

Các câu lệnh sql thuần túy hoặc nhập dữ liệu cũng được hỗ trợ.

Hầu hết các công cụ cơ sở dữ liệu nên hỗ trợ kết xuất cơ sở dữ liệu của bạn vào một tệp. Dù sao thì tôi cũng biết MySQL. Đây sẽ chỉ là một tệp văn bản, vì vậy bạn có thể gửi nó đến Subversion hoặc bất cứ thứ gì bạn sử dụng. Nó cũng sẽ dễ dàng chạy một khác biệt trên các tệp.

Nếu bạn đang sử dụng SQL Server, thật khó để đánh bại Data Dude (hay còn gọi là Phiên bản Cơ sở dữ liệu của Visual Studio). Một khi bạn hiểu rõ, việc so sánh giản đồ giữa phiên bản cơ sở dữ liệu được kiểm soát nguồn của bạn và phiên bản đang sản xuất thật dễ dàng. Và với một cú nhấp chuột, bạn có thể tạo DDL khác biệt của mình.

Có một video hướng dẫn trên MSDN rất hữu ích.

Tôi biết về DBMS_METADATA và Toad, nhưng nếu ai đó có thể nghĩ ra Data Dude cho Oracle thì cuộc sống sẽ thực sự ngọt ngào.

Có các câu lệnh tạo bảng ban đầu của bạn trong bộ điều khiển phiên bản, sau đó thêm các câu lệnh bảng thay đổi, nhưng không bao giờ chỉnh sửa tệp, chỉ thêm tệp thay đổi lý tưởng được đặt tên tuần tự hoặc thậm chí dưới dạng "tập hợp thay đổi", vì vậy bạn có thể tìm thấy tất cả các thay đổi cho một triển khai cụ thể.

Phần khó nhất mà tôi có thể thấy, là theo dõi các phụ thuộc, ví dụ: đối với một bảng triển khai cụ thể B có thể cần được cập nhật trước bảng A.

Đối với Oracle, tôi sử dụng Toad , có thể kết xuất một lược đồ vào một số tệp rời rạc (ví dụ: một tệp cho mỗi bảng). Tôi có một số tập lệnh quản lý bộ sưu tập này trong Perforce, nhưng tôi nghĩ rằng nó sẽ dễ dàng thực hiện được trong bất kỳ hệ thống kiểm soát sửa đổi nào.

Hãy xem gói oracle DBMS_METADATA.

Đặc biệt, các phương pháp sau đặc biệt hữu ích:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

Một khi bạn đã quen với cách chúng hoạt động (khá dễ hiểu), bạn có thể viết một script đơn giản để kết xuất các kết quả của các phương pháp đó vào các tệp văn bản có thể được đặt dưới sự kiểm soát của nguồn. Chúc may mắn!

Không chắc liệu có điều gì đó đơn giản cho MSSQL hay không.

Tôi viết các tập lệnh phát hành db của mình song song với viết mã và giữ các tập lệnh phát hành trong một phần cụ thể của dự án trong SS. Nếu tôi thực hiện thay đổi đối với mã yêu cầu thay đổi db, thì tôi cập nhật tập lệnh phát hành cùng lúc. Trước khi phát hành, tôi chạy tập lệnh phát hành trên db dev sạch (cấu trúc được sao chép khôn ngoan từ quá trình sản xuất) và thực hiện thử nghiệm cuối cùng trên đó.

Tôi đã làm việc này liên tục trong nhiều năm - quản lý (hoặc cố gắng quản lý) các phiên bản lược đồ. Các cách tiếp cận tốt nhất phụ thuộc vào các công cụ bạn có. Nếu bạn có thể nhận được công cụ Phần mềm Nhiệm vụ "Trình quản lý lược đồ", bạn sẽ có tình hình tốt. Oracle có một công cụ riêng, kém hơn cũng được gọi là "Trình quản lý lược đồ" (gây nhầm lẫn nhiều nhỉ?) Mà tôi không khuyên dùng.

Nếu không có công cụ tự động (xem các nhận xét khác ở đây về Data Dude) thì bạn sẽ sử dụng trực tiếp các tập lệnh và tệp DDL. Chọn một cách tiếp cận, ghi lại nó và tuân theo nó một cách chặt chẽ. Tôi muốn có khả năng tạo lại cơ sở dữ liệu tại bất kỳ thời điểm nào, vì vậy tôi muốn xuất toàn bộ DDL của toàn bộ cơ sở dữ liệu (nếu tôi là DBA) hoặc lược đồ nhà phát triển (nếu tôi đang ở trong sản phẩm -chế độ phát triển).

PLSQL Developer, một công cụ từ All Arround Automations, có một plugin cho các kho lưu trữ hoạt động OK (nhưng không tốt) với Visual Source Safe.

Từ web:

Trình cắm Kiểm soát Phiên bản cung cấp sự tích hợp chặt chẽ giữa PL / SQL Developer IDE >> và bất kỳ Hệ thống Kiểm soát Phiên bản nào hỗ trợ Đặc tả Giao diện SCC của Microsoft. >> Điều này bao gồm các Hệ thống Kiểm soát Phiên bản phổ biến nhất như Microsoft Visual SourceSafe, >> Merant PVCS và MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

ER Studio cho phép bạn đảo ngược giản đồ cơ sở dữ liệu của mình vào công cụ và sau đó bạn có thể so sánh nó với cơ sở dữ liệu trực tiếp.

Ví dụ: Đảo ngược lược đồ phát triển của bạn vào ER Studio - so sánh nó với bản sản xuất và nó sẽ liệt kê tất cả các điểm khác biệt. Nó có thể viết kịch bản các thay đổi hoặc chỉ đẩy chúng tự động.

Khi bạn có một lược đồ trong ER Studio, bạn có thể lưu tập lệnh tạo hoặc lưu nó dưới dạng tệp nhị phân độc quyền và lưu nó trong kiểm soát phiên bản. Nếu bạn muốn quay lại phiên bản trước đây của lược đồ, chỉ cần kiểm tra và đẩy nó lên nền tảng db của bạn.

Có một "khung di chuyển cơ sở dữ liệu" PHP5 được gọi là Ruckusing. Tôi chưa sử dụng nó, nhưng các ví dụ cho thấy ý tưởng, nếu bạn sử dụng ngôn ngữ để tạo cơ sở dữ liệu và khi cần, bạn chỉ phải theo dõi các tệp nguồn.

Bạn có thể sử dụng Microsoft SQL Server Data Tools trong visual studio để tạo tập lệnh cho các đối tượng cơ sở dữ liệu như một phần của Dự án SQL Server. Sau đó, bạn có thể thêm các tập lệnh vào kiểm soát nguồn bằng cách sử dụng tích hợp kiểm soát nguồn được tích hợp trong studio trực quan. Ngoài ra, SQL Server Projects cho phép bạn xác minh các đối tượng cơ sở dữ liệu bằng trình biên dịch và tạo các tập lệnh triển khai để cập nhật cơ sở dữ liệu hiện có hoặc tạo một cơ sở dữ liệu mới.

Chúng tôi đã sử dụng Phiên bản Cơ sở dữ liệu Hệ thống MS Team với thành công khá tốt. Nó tích hợp với kiểm soát phiên bản TFS và Visual Studio ít nhiều một cách liền mạch và cho phép chúng tôi quản lý các tài liệu lưu trữ, chế độ xem, v.v. một cách dễ dàng. Giải quyết xung đột có thể là một vấn đề khó khăn, nhưng lịch sử phiên bản sẽ hoàn tất sau khi hoàn tất. Sau đó, việc chuyển đổi sang QA và sản xuất cực kỳ đơn giản.

Tuy nhiên, công bằng mà nói thì đó là một sản phẩm phiên bản 1.0 và không phải là không có một số vấn đề.

Schema Compare cho Oracle là một công cụ được thiết kế đặc biệt để di chuyển các thay đổi từ cơ sở dữ liệu Oracle của chúng tôi sang một cơ sở dữ liệu khác. Vui lòng truy cập URL bên dưới để biết liên kết tải xuống, nơi bạn sẽ có thể sử dụng phần mềm để dùng thử đầy đủ chức năng.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

Trong trường hợp không có VCS để thay đổi bảng, tôi đã ghi nhật ký chúng vào wiki. Ít nhất sau đó tôi có thể biết khi nào và tại sao nó được thay đổi. Còn lâu mới hoàn hảo vì không phải ai cũng làm được và chúng tôi có nhiều phiên bản sản phẩm đang được sử dụng, nhưng còn hơn không.

Tôi muốn giới thiệu một trong hai cách tiếp cận. Đầu tiên, đầu tư vào PowerDesigner từ Sybase. Phiên bản doanh nghiệp. Nó cho phép bạn thiết kế các mô hình dữ liệu Vật lý và hơn thế nữa. Nhưng nó đi kèm với một kho lưu trữ cho phép bạn kiểm tra các mô hình của mình. Mỗi lần đăng ký mới có thể là một phiên bản mới, nó có thể so sánh bất kỳ phiên bản nào với bất kỳ phiên bản nào khác và thậm chí với những gì có trong cơ sở dữ liệu của bạn tại thời điểm đó. Sau đó, nó sẽ đưa ra một danh sách mọi điểm khác biệt và hỏi cái nào nên được di chuyển… và sau đó nó xây dựng tập lệnh để thực hiện điều đó. Nó không rẻ nhưng nó là một món hời với giá gấp đôi và ROI của nó là khoảng 6 tháng.

Ý tưởng khác là bật kiểm tra DDL (hoạt động trong Oracle). Thao tác này sẽ tạo một bảng với mọi thay đổi bạn thực hiện. Nếu bạn truy vấn những thay đổi từ dấu thời gian mà lần cuối bạn chuyển các thay đổi trong cơ sở dữ liệu của mình sang sản phẩm ngay bây giờ, bạn sẽ có một danh sách sắp xếp mọi thứ bạn đã làm. Một số mệnh đề trong đó loại bỏ các thay đổi tổng bằng 0 như tạo bảng foo; tiếp theo là thả bảng foo; và bạn có thể DỄ DÀNG xây dựng một tập lệnh mod. Tại sao giữ các thay đổi trong wiki, đó là công việc gấp đôi. Hãy để cơ sở dữ liệu theo dõi chúng cho bạn.

Hai cuốn sách khuyến nghị: "Tái cấu trúc cơ sở dữ liệu" của Ambler và Sadalage và "Kỹ thuật cơ sở dữ liệu nhanh nhẹn" của Ambler.

Ai đó đã đề cập đến Rails Migrations. Tôi nghĩ rằng chúng hoạt động tuyệt vời, ngay cả bên ngoài các ứng dụng Rails. Tôi đã sử dụng chúng trên một ứng dụng ASP với SQL Server mà chúng tôi đang trong quá trình chuyển sang Rails. Bạn tự kiểm tra các tập lệnh di chuyển vào VCS. Đây là một bài đăng của Pragmatic Dave Thomas về chủ đề này.