Xử lý các thay đổi lược đồ cơ sở dữ liệu khi đẩy các phiên bản mới

Trong thời gian phát triển nặng nề, lược đồ cơ sở dữ liệu thay đổi nhanh chóng và liên tục, và vào thời điểm bản phát hành beta hàng tuần của chúng tôi xuất hiện, lược đồ đã thay đổi rất nhiều đến mức tùy chọn hợp lý duy nhất là loại bỏ tất cả các bảng tôi có thể và sao chép các phiên bản mới từ cơ sở dữ liệu dev của tôi. Rõ ràng, điều này sẽ không hoạt động một khi chúng tôi khởi chạy, vì dữ liệu sản xuất là một công thức cho thảm họa, vì vậy tôi đã tự hỏi những chiến lược nào được đưa ra để quản lý các thay đổi lược đồ cơ sở dữ liệu từ phiên bản này / phiên bản khác?

Một số tôi đã tìm thấy hoặc có kinh nghiệm:

1. Chuyển thẳng từ cơ sở dữ liệu này sang cơ sở dữ liệu khác (những gì tôi đang làm bây giờ)
2. Duy trì tệp UPDATE.sql bằng các câu lệnh SQL được chạy thông qua tập lệnh hoặc bằng tay.
3. Duy trì tệp update.php với giá trị "phiên bản lược đồ db" tương ứng trong cơ sở dữ liệu hoạt động

Tùy chọn thứ ba có vẻ hợp lý nhất, nhưng vẫn tồn tại khả năng truy vấn SQL được xây dựng kém không thành công giữa tập lệnh, khiến cơ sở dữ liệu ở trạng thái cập nhật một nửa, cần phải khôi phục bản sao lưu.

Có vẻ như không có vấn đề gì, nhưng nó đã xảy ra, vì chúng tôi là một nhóm, chúng tôi sử dụng phpMyAdmin và dường như tôi thậm chí không thể dựa vào bản thân mình nhớ sao chép câu lệnh SQL đã thực thi để dán vào tệp update.php. Khi bạn điều hướng đến một trang khác, tôi phải viết lại câu lệnh SQL bằng tay hoặc đảo ngược sự thay đổi của tôi và làm lại.

Tôi đoán những gì tôi đang hy vọng là một giải pháp không ảnh hưởng đến quy trình phát triển được thiết lập của chúng tôi?

Tự động hóa. Tự động hóa. Tự động hóa.

Bạn đang đi đúng hướng với số phiên bản DB rõ ràng, nhưng tôi sẽ tiến thêm một bước và làm cho mã nhận thức rõ ràng về chính xác lược đồ mà nó dự kiến ​​sẽ hoạt động (ví dụ: bằng cách thực hiện kịch bản DDL thực tế và có trình cập nhật phân tích cú pháp ); sau đó tại thời điểm cập nhật, bạn chỉ phải khám phá lược đồ hiện có thông qua siêu dữ liệu cơ sở dữ liệu và INSERT / DROP / ALTER khi cần thiết, bất kể từ phiên bản nào đến phiên bản bạn đang cập nhật. (Bạn cũng có thể giữ một số phiên bản rõ ràng trong chính cơ sở dữ liệu và phân phối toàn bộ lịch sử lược đồ với trình cài đặt để bạn thậm chí không cần khám phá lược đồ.)

Lỗi cú pháp tiềm năng trong tập lệnh SQL cập nhật là một vấn đề, nhưng bạn có thể giải quyết điều đó bằng cách xác minh rằng trình cập nhật chỉ có thể tạo ra các câu lệnh DDL chính xác. (Bằng chứng chính thức hầu như không bao giờ có giá trị trong phát triển phần mềm doanh nghiệp - quá nhiều nỗ lực cho quá ít sự đảm bảo - nhưng tôi cảm thấy rằng tính toàn vẹn của cơ sở dữ liệu là một trong số ít trường hợp ngoại lệ: SQL cơ bản không phải là ngôn ngữ đặc biệt khó nắm bắt chính thức và lợi ích của bảo vệ dữ liệu sản xuất lớn đến mức hầu như bất kỳ số lượng nỗ lực trước một lần nào đều hợp lý, đặc biệt nếu nó phải hoạt động cho các cài đặt không giám sát,)

Phiên bản lược đồ cơ sở dữ liệu là cách để đi - mỗi phiên bản chỉ có một thay đổi đối với cơ sở dữ liệu hoặc ít nhất là các thay đổi có thể được hoàn nguyên toàn bộ. DBDeploy là một công cụ tuyệt vời để tự động hóa điều đó.

Một số điều tôi đã học được hữu ích là:

1. Luôn kiểm tra thay đổi cục bộ của bạn và kiểm tra mã của bạn với nó, chỉ cần ALTERvượt qua là không đủ
2. Bạn cần đồng bộ hóa để thực hiện thay đổi của họ trước - một trang wiki đơn giản nơi bạn có thể "lấy số" làm việc rất tốt cho nhóm của tôi.
3. Đừng cố gắng sửa đổi thay đổi bị hỏng, thêm một thay đổi mới để phủ nhận nó, điều đó không gây đau đớn
4. Mã của bạn phụ thuộc vào các thay đổi đó - hãy chắc chắn liên kết các vấn đề trong hệ thống theo dõi lỗi của bạn với các thay đổi DB. Điều đó rất hữu ích tại thời điểm triển khai.
5. Bao gồm các thay đổi DB cho CI của bạn - hãy áp dụng các thay đổi của bạn cho cơ sở dữ liệu CI trên cam kết. Ngoài ra, nếu bạn có bất kỳ bài kiểm tra nào sử dụng cơ sở dữ liệu, hãy chạy chúng trên cam kết.

Vì bạn đang sử dụng phpMyAdmin, nên tôi giả sử bạn cũng đang sử dụng MySQL.

Hãy xem sơ đồ Mô hình EER trong MySQL Workbench. Họ đã giúp tôi rất nhiều trong việc duy trì và cập nhật các lược đồ.

Đầu tiên, bạn có thể đồng bộ hóa mô hình với nguồn cơ sở dữ liệu. Vì vậy, những thay đổi trong sơ đồ được đẩy dưới dạng các lệnh ALTER TABLE. Điều này cho phép bạn thực hiện các thay đổi lược đồ của mình trên sơ đồ, giữ cho nó luôn cập nhật trong khi cũng đẩy các bản cập nhật vào cơ sở dữ liệu phát triển của bạn khi cần.

Thứ hai, bạn có thể đảo ngược sơ đồ EER từ nguồn cơ sở dữ liệu. Điều này có thể hữu ích bằng cách thay đổi cơ sở dữ liệu phát triển và cập nhật cơ sở dữ liệu sản xuất vì nó sẽ tính toán sự khác biệt.

Thứ ba, nó có thể được sử dụng để hỗ trợ tạo SQL nên đi vào tệp "update.sql" của bạn.

Nhược điểm:

Các kích hoạt và ràng buộc cơ sở dữ liệu là một vấn đề với trình cập nhật đồng bộ hóa. Nó dường như không biết thứ tự đúng của mọi thứ. Các ràng buộc khóa ngoài thường tạo ra lỗi, nhưng điều này có thể được giải quyết bằng cách chỉnh sửa SQL mà nó tạo ra.

Đây không phải là một công cụ di chuyển dữ liệu. Bất kỳ thay đổi nào nằm ngoài lược đồ thuần túy vẫn sẽ cần SQL tùy chỉnh.

Hãy xem http://south.aeracode.org - đó là thư viện di chuyển DB cho Django (khung Python) nhưng:

1. bạn có thể có được những ý tưởng tuyệt vời từ nó (và thậm chí có thể tìm thấy một bản sao PHP)
2. bạn thực sự có thể sử dụng nó một cách độc lập với phần còn lại của Django để quản lý các bảng ứng dụng PHP / MySQL của bạn.

Nó cũng có thể tạo các kịch bản cập nhật lược đồ; nó cũng xử lý đảo ngược thay đổi tự động hầu hết thời gian.