Làm thế nào để bạn thay đổi phiên bản / theo dõi các bảng SQL?

Khi làm việc trong một nhóm các nhà phát triển, nơi mọi người đang thực hiện thay đổi cho các bảng cục bộ và các bảng phát triển, làm thế nào để bạn giữ tất cả các thay đổi đồng bộ hóa? Một tệp nhật ký trung tâm nơi mọi người giữ thay đổi sql của họ? Một trang wiki để theo dõi các thay đổi của bảng lệnh, các tệp .sql riêng lẻ mà các nhà phát triển có thể chạy để đưa db cục bộ của họ lên phiên bản mới nhất? Tôi đã sử dụng một số giải pháp này và tôi đang cố gắng để có được một giải pháp vững chắc cùng hoạt động, vì vậy tôi đánh giá cao ý tưởng của bạn.

Tôi sử dụng một công cụ di chuyển cơ sở dữ liệu dựa trên mã và giữ mã di chuyển trong kiểm soát nguồn.

Bằng cách sử dụng dấu thời gian làm số phiên bản, bất kỳ số lượng nhà phát triển nào hầu hết đều miễn phí để thêm di chuyển khi họ muốn và chúng tôi có thể chạy công cụ Di chuyển đối với bất kỳ bản sao nào của cơ sở dữ liệu của chúng tôi một cách tự tin.

Tôi đã từng sử dụng SQL ScScript dưới sự kiểm soát phiên bản, nhưng tìm cách tiếp cận dựa trên mã, dễ dàng hơn nhiều để làm việc vì tất cả chúng đều nằm trong một "điểm" logic và có thể thực thi tất cả các tập lệnh cần thiết bằng một lệnh.

Tôi không tự làm điều đó, nhưng một số nhà phát triển duy trì một tập hợp các tập lệnh SQL dưới sự kiểm soát nguồn, khi được thực thi, có thể tạo lại các bảng cơ sở dữ liệu cho mục đích thử nghiệm và xây dựng cơ sở dữ liệu trống cho mục đích sản xuất.

Kỹ thuật tương tự có thể được sử dụng để phiên bản cơ sở dữ liệu tại trang web của khách hàng, khi các trường hoặc bảng cần được thêm hoặc xóa hoặc chuyển đổi dữ liệu cần phải diễn ra.

Xây dựng tập lệnh dưới sự kiểm soát phiên bản và tích hợp liên tục để xác minh chúng

Một cách tiếp cận hiệu quả với tôi là để mỗi nhà phát triển làm việc với lược đồ riêng mà họ có thể làm những gì họ thích. Lược đồ của họ có thể bị phá hủy và được điền với dữ liệu thử nghiệm được lấy từ một tập lệnh được kiểm soát phiên bản mà tất cả các nhà phát triển đã đóng góp.

Bản dựng tích hợp liên tục hàng đêm đã lấy phiên bản mới nhất của tất cả các tập lệnh và cố gắng xây dựng cơ sở dữ liệu kiểm tra gắn kết từ chúng. Sau đó, ứng dụng đã có một loạt các thử nghiệm tích hợp và chức năng chạy với nó để xác minh rằng lược đồ hiện tại phù hợp với ứng cử viên phát hành hiện tại.

Trước khi bắt đầu con đường này, đã có một thiết kế cơ sở dữ liệu khá vững chắc và một DBA luôn để mắt đến mọi thứ để ngăn chặn các nhà phát triển phát điên với sự bất thường và những điều kinh hoàng khác.

Kiểm soát phiên bản đã giúp rất nhiều ở đây vì những thay đổi về kịch bản ngay lập tức rõ ràng. Chúng tôi cũng đã sử dụng VERSIONbảng cơ sở dữ liệu để xác định trạng thái chung của cơ sở dữ liệu. Đây là một chuỗi số nguyên đơn giản và không được liên kết với bất kỳ ứng dụng cụ thể nào.

Nhìn chung, nó hoạt động tốt và có nghĩa là các nhà phát triển đã không còn sợ thay đổi các tầng kiên trì vì họ luôn có thể quay lại các lược đồ của riêng mình mà không ảnh hưởng đến người khác.

Nếu bạn đang ở trong một cửa hàng MS, Visual Studio 2010 có một số công cụ kiểm soát phiên bản cơ sở dữ liệu đẹp, cũng có thể tạo ra các kịch bản thay đổi / triển khai dựa trên sự khác biệt giữa hai cơ sở dữ liệu.

Cùng với việc giữ schemata và các tập lệnh SQL khác dưới sự kiểm soát phiên bản, một thực hành tiện dụng khác là duy trì bảng 'phiên bản lược đồ' trong DB thực tế .

create table schema_migrations (
    `appliedAt` timestamp not null default CURRENT_TIMESTAMP,
    `migrationCode` varchar(256) not null,
    `extraNotes` varchar(256),
    primary key (`migrationCode`)
)

Doctrine có một công cụ Di chuyển tuyệt vời: http://www.doctrine-project.org/documentation/manual/1_2/en/migations , phần hay nhất là chúng được tự động tạo hoặc có thể dễ dàng mã hóa bằng tay.

Cách tiếp cận mà tôi sử dụng là cung cấp một bảng cho các tham số. Bảng này sẽ có một cặp tên / giá trị cho phiên bản mà cơ sở dữ liệu được bật. Điều này mang lại cho tôi hai lợi ích: Tôi có cách xác minh cơ sở dữ liệu chỉ sửa lỗi đã được áp dụng thông qua ứng dụng và tôi có thể sử dụng giá trị đó cho các tập lệnh SQL của mình.

Tập lệnh SQL sẽ tạo các bảng mới, thay đổi các cột và bất kỳ công việc nào cần thiết trên cơ sở dữ liệu để quảng bá tập lệnh từ phiên bản trước đó. Lý tưởng nhất là tôi cũng sẽ có một kịch bản rollback, nhưng hầu hết thời gian tôi không có.

BTW, toàn bộ cách tiếp cận này đã được tự động hóa như một phần của Ruby on Rails, hoàn chỉnh với các kịch bản rollback. Tôi thích ý tưởng về điều đó, nhưng không phải tất cả các khung làm điều đó. Khi tôi không sử dụng Ruby on Rails, tôi sử dụng cách tiếp cận được nêu ở trên.