Phương pháp kiểm soát phiên bản SQL

Question

Có một số câu hỏi về SO về kiểm soát phiên bản cho SQL và nhiều tài nguyên trên web, nhưng tôi không thể tìm thấy thứ gì đó hoàn toàn bao gồm những gì tôi đang cố gắng thực hiện.

Trước hết, tôi đang nói về một phương pháp ở đây. Tôi quen thuộc với các ứng dụng kiểm soát nguồn khác nhau và tôi quen thuộc với các công cụ như So sánh SQL của Red Gate, v.v. và tôi biết cách viết một ứng dụng để kiểm tra mọi thứ trong và ngoài hệ thống kiểm soát nguồn của tôi một cách tự động. Nếu có một công cụ đặc biệt hữu ích trong việc cung cấp một phương pháp hoàn toàn mới hoặc có chức năng hữu ích và không phổ biến thì tuyệt vời, nhưng đối với các nhiệm vụ được đề cập ở trên, tôi đã được thiết lập.

Các yêu cầu mà tôi đang cố gắng để đáp ứng là:

• Giản đồ cơ sở dữ liệu và bảng tra cứu dữ liệu được phiên bản
• script DML cho sửa dữ liệu cho các bảng lớn được phiên bản
• Một máy chủ có thể được quảng cáo từ phiên bản N lên phiên bản N + X trong đó X không phải lúc nào cũng là 1
• Mã không được sao chép trong hệ thống kiểm soát phiên bản - ví dụ: nếu tôi thêm cột vào bảng tôi không muốn có để đảm bảo rằng thay đổi trong cả tập lệnh tạo và thay đổi ipt
• Hệ thống này cần phải hỗ trợ nhiều khách hàng là những người có các phiên bản khác nhau cho các ứng dụng (cố gắng để có được tất cả chúng lên để trong vòng 1 hoặc 2 phiên bản, nhưng không có được nêu ra)

Một số tổ chức giữ các kịch bản thay đổi theo phong trong phiên bản điều khiển của họ và để có được từ phiên bản N đến N + 3 bạn sẽ phải chạy các kịch bản cho N-> N + 1 rồi N + 1-> N + 2 rồi N + 2-> N + 3. Một số kịch bản này có thể lặp lại (ví dụ, một cột được thêm vào nhưng sau đó nó được thay đổi để thay đổi kiểu dữ liệu). Chúng tôi đang cố gắng tránh sự lặp lại đó vì một số DB khách hàng có thể rất lớn, vì vậy những thay đổi này có thể mất nhiều thời gian hơn mức cần thiết.

Một số tổ chức đơn giản sẽ giữ tập lệnh xây dựng cơ sở dữ liệu đầy đủ ở mỗi cấp phiên bản, sau đó sử dụng công cụ như So sánh SQL để đưa cơ sở dữ liệu lên một trong các phiên bản đó. Vấn đề ở đây là việc trộn lẫn các kịch bản DML có thể là một vấn đề. Hãy tưởng tượng một kịch bản mà tôi thêm một cột, sử dụng một kịch bản DML để điền vào cột đã nói, sau đó trong một phiên bản sau đó tên cột được thay đổi.

Có lẽ có một số giải pháp lai? Có lẽ tôi chỉ yêu cầu quá nhiều? Bất kỳ ý tưởng hoặc đề nghị sẽ được đánh giá rất nhiều mặc dù.

Nếu người kiểm duyệt nghĩ rằng điều này sẽ phù hợp hơn với tư cách là một wiki cộng đồng, vui lòng cho tôi biết.

Cảm ơn!

Answer 1

Tôi đã vật lộn với điều này trong vài năm trước khi gần đây áp dụng một chiến lược dường như hoạt động khá tốt. Những điểm mấu chốt Tôi sống theo:

• Cơ sở dữ liệu không cần phải được phiên bản độc lập với ứng dụng
• Tất cả các kịch bản cập nhật cơ sở dữ liệu nên được idempotent

Kết quả là, tôi không còn tạo ra bất kỳ loại bảng phiên bản. Tôi chỉ cần thêm các thay đổi vào một chuỗi số các tệp .sql có thể được áp dụng tại bất kỳ thời điểm nào mà không làm hỏng cơ sở dữ liệu. Nếu nó dễ dàng hơn, tôi sẽ viết một màn hình cài đặt đơn giản cho ứng dụng để cho phép quản trị viên chạy các tập lệnh này bất cứ khi nào họ muốn.

Dĩ nhiên, phương pháp này không áp đặt một vài yêu cầu về thiết kế cơ sở dữ liệu:

• Mọi thay đổi schema được thực hiện thông qua kịch bản - không có công việc GUI.
• Phải chú ý thêm để đảm bảo tất cả các khóa, ràng buộc, v.v. được đặt tên để chúng có thể được tham chiếu bởi tập lệnh cập nhật sau, nếu cần.
• Tất cả tập lệnh cập nhật phải kiểm tra các điều kiện hiện có.

Ví dụ từ một dự án gần đây:

001.sql:

if object_id(N'dbo.Registrations') is null 
begin 
    create table dbo.Registrations 
    (
     [Id]     uniqueidentifier not null, 
     [SourceA]    nvarchar(50)  null, 
     [SourceB]    nvarchar(50)  null, 
     [Title]     nvarchar(50)  not null, 
     [Occupation]   nvarchar(50)  not null, 
     [EmailAddress]   nvarchar(100) not null, 
     [FirstName]    nvarchar(50)  not null, 
     [LastName]    nvarchar(50)  not null, 
     [ClinicName]   nvarchar(200) not null, 
     [ClinicAddress]   nvarchar(50)  not null, 
     [ClinicCity]   nvarchar(50)  not null, 
     [ClinicState]   nchar(2)   not null, 
     [ClinicPostal]   nvarchar(10)  not null, 
     [ClinicPhoneNumber]  nvarchar(10)  not null, 
     [ClinicPhoneExtension] nvarchar(10)  not null, 
     [ClinicFaxNumber]  nvarchar(10)  not null, 
     [NumberOfVets]   int    not null, 
     [IpAddress]    nvarchar(20)  not null, 
     [MailOptIn]    bit    not null, 
     [EmailOptIn]   bit    not null, 
     [Created]    datetime   not null, 
     [Modified]    datetime   not null, 
     [Deleted]    datetime   null 
    ); 
end 

if not exists(select 1 from information_schema.table_constraints where constraint_name = 'pk_registrations') 
    alter table dbo.Registrations add 
     constraint pk_registrations primary key nonclustered (Id); 

if not exists (select 1 from sysindexes where [name] = 'ix_registrations_created') 
    create clustered index ix_registrations_created 
     on dbo.Registrations(Created); 

if not exists (select 1 from sysindexes where [name] = 'ix_registrations_email') 
    create index ix_registrations_email 
     on dbo.Registrations(EmailAddress); 

if not exists (select 1 from sysindexes where [name] = 'ix_registrations_email') 
    create index ix_registrations_name_and_clinic 
     on dbo.Registrations (FirstName, 
           LastName, 
           ClinicName); 

002.sql

/********************************************************************** 
    The original schema allowed null for these columns, but we don't want 
    that, so update existing nulls and change the columns to disallow 
    null values 
*********************************************************************/ 

update dbo.Registrations set SourceA = '' where SourceA is null; 
update dbo.Registrations set SourceB = '' where SourceB is null; 
alter table dbo.Registrations alter column SourceA nvarchar(50) not null; 
alter table dbo.Registrations alter column SourceB nvarchar(50) not null; 

/********************************************************************** 
    The client wanted to modify the signup form to include a fax opt-in 
*********************************************************************/ 

if not exists 
(
    select 1 
     from information_schema.columns 
    where table_schema = 'dbo' 
     and table_name = 'Registrations' 
     and column_name = 'FaxOptIn' 
) 
alter table dbo.Registrations 
    add FaxOptIn bit null 
     constraint df_registrations_faxoptin default 0; 

003.sql, 004.sql, vv ...

Tại bất kỳ thời điểm nào, tôi có thể chạy toàn bộ chuỗi tập lệnh dựa vào dữ liệu ase ở bất kỳ trạng thái nào và biết rằng mọi thứ sẽ ngay lập tức được tăng tốc với phiên bản hiện tại của ứng dụng. Bởi vì mọi thứ đều được viết kịch bản, dễ dàng hơn nhiều khi xây dựng một trình cài đặt đơn giản để thực hiện việc này và việc thêm các thay đổi lược đồ vào kiểm soát nguồn là không có vấn đề gì cả.

Answer 2

cho loại sự cố này sử dụng Hệ thống nhóm studio trực quan 2008 để kiểm soát phiên bản cơ sở dữ liệu sql của bạn.

Trong tsf không có.tính năng avialbe như

• Datacompare
• Schemacompare
• phiên bản kiểm soát

về kiểm soát phiên bản cơ sở dữ liệu: http://www.codinghorror.com/blog/2006/12/is-your-database-under-version-control.html để biết thêm chi tiết kiểm tra: http://msdn.microsoft.com/en-us/library/ms364062(VS.80).aspx

Answer 3

Bạn đã có khá khắt khe thiết lập các yêu cầu, tôi không chắc liệu bạn sẽ tìm thấy thứ gì đó đặt kiểm tra trong tất cả các hộp, espe cially nhiều lược đồ đồng thời và điều khiển phiên bản thông minh.

Công cụ hứa hẹn nhất mà tôi đã đọc về loại phù hợp đó là Liquibase.
Dưới đây là một số liên kết bổ sung:

• http://en.wikipedia.org/wiki/LiquiBase
• http://www.ibm.com/developerworks/java/library/j-ap08058/index.html

Answer 4

Vâng, bạn đang yêu cầu cho rất nhiều, nhưng chúng tất cả các điểm thực sự thích hợp! Ở đây tại Red Gate, chúng tôi đang hướng tới một giải pháp phát triển cơ sở dữ liệu hoàn chỉnh với phần mở rộng SSMS kiểm soát nguồn SQL của chúng tôi và chúng tôi đang đối mặt với những thách thức tương tự.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

Đối với việc phát hành sắp tới, chúng tôi đang hỗ trợ hoàn toàn thay đổi lược đồ, và hỗ trợ dữ liệu tĩnh gián tiếp thông qua dữ liệu SQL của chúng tôi so sánh công cụ. Tất cả các thay đổi được lưu dưới dạng tập lệnh tạo, mặc dù khi bạn đang cập nhật hoặc triển khai vào cơ sở dữ liệu, công cụ sẽ đảm bảo rằng các thay đổi được áp dụng thích hợp làm ALTER hoặc TẠO.

Yêu cầu khó khăn nhất mà chưa có giải pháp đơn giản là quản lý và triển khai phiên bản mà bạn mô tả rất rõ ràng. Nếu bạn thực hiện các thay đổi phức tạp đối với lược đồ và dữ liệu, có thể không tránh khỏi kịch bản di chuyển thủ công được lấy giữa hai phiên bản liền kề, vì không phải tất cả 'intent' luôn được lưu cùng với phiên bản mới hơn. Đổi tên cột là một ví dụ điển hình. Giải pháp có thể là cho một hệ thống được phát minh để tiết kiệm ý định, hoặc nếu điều này quá phức tạp, cho phép người dùng cung cấp một kịch bản tùy chỉnh để thực hiện thay đổi phức tạp. Một số loại khung quản lý phiên bản sẽ quản lý chúng và "kỳ diệu" xây dựng các kịch bản triển khai từ hai phiên bản tùy ý.

Answer 5

Chúng tôi đang sử dụng Trình kiểm tra SQL để lưu lược đồ cơ sở dữ liệu dưới sự kiểm soát phiên bản. Tôi cũng đã thử VS2010, nhưng theo quan điểm của tôi, VS là quá phức tạp đối với các dự án nhỏ và vừa. Với SQL Examiner tôi chủ yếu làm việc với SSMS và sử dụng SQL Examiner để kiểm tra cập nhật cho SVN (TFS và SourceSafe cũng được hỗ trợ, nhưng tôi chưa bao giờ thử nó).

Dưới đây là mô tả về cách tiếp cận của SQL Examiner: How to get your database under version control

Answer 6

Thử DBSourceTools. (http://dbsourcetools.codeplex.com)
Nguồn mở của nó và được thiết kế đặc biệt để viết toàn bộ cơ sở dữ liệu - bảng, khung nhìn, procs vào đĩa và sau đó tạo lại cơ sở dữ liệu đó thông qua mục tiêu triển khai.
Bạn có thể tập lệnh tất cả dữ liệu hoặc chỉ định bảng nào cho dữ liệu tập lệnh.
Ngoài ra, bạn có thể nén kết quả để phân phối.
Chúng tôi sử dụng nó để kiểm soát nguồn cơ sở dữ liệu và kiểm tra các bản vá cập nhật cho các bản phát hành mới.
Trong back-end nó được xây dựng xung quanh SMO, và do đó hỗ trợ SQL 2000, 2005 và 2008.
DBDiff được tích hợp, để cho phép so sánh lược đồ.
Hãy vui vẻ, - Nathan.