Tôi đã suy nghĩ và đọc rất nhiều về chủ đề này. Đây là một chủ đề rộng lớn về kiểm soát cấu hình và chiến lược quản lý thay đổi. CMMI có một tên miền trong chủ đề này. Ngay cả trong các công ty có chứng nhận CMMI 3-5, đôi khi họ không kiểm soát phiên bản cơ sở dữ liệu của họ.
Câu hỏi này nên được trả lời trong khi ghi nhớ những hạn chế .
- Bạn có một người quản lý và mọi DDL được thực hiện bởi người quản lý này.
- Những người khác có khả năng thực thi các câu lệnh DDL.
- Bạn chỉ cần ghi nhật ký những thay đổi đã được thực hiện nhưng bạn không cần so sánh sự khác biệt lớn.
- Thiết kế cơ sở dữ liệu của bạn được thực hiện thông qua công cụ bên ngoài sau đó được xuất bản vào cơ sở dữ liệu. Công cụ bên ngoài này có thể là các tập lệnh DDL trong kiểm soát nguồn. Nhưng điểm quan trọng là bạn kiểm soát nguồn này sau đó xuất bản vào cơ sở dữ liệu.
- Bạn không cần phải biết thay đổi tức thời nhưng theo thời gian: tức là hàng giờ, hàng ngày.
- Bạn có một cấu trúc máy chủ được xác định: Phát triển, Thử nghiệm, Sản xuất. Và một chiến lược thử nghiệm tốt.
trả lời 1
- nếu 1, 4,6 là đúng thì bạn có thể sử dụng điều khiển nguồn bên ngoài. Ví dụ
- Embercadero có một công cụ quản lý thay đổi cơ sở dữ liệu ( http://www.embarcadero.com/products/db-change-manager-xe ). Có khả năng đảo ngược cơ sở dữ liệu (Oracle) và đưa nó vào kiểm soát nguồn của họ. Sau đó, bất kỳ số lượng nhà phát triển, dba có thể tiếp cận lược đồ này và thay đổi nó.
- Oracle SQL Designer tương tự như phương pháp này.
- Đặt bạn tạo tập lệnh bảng để kiểm soát nguồn (svn, mercurial, v.v.) và duy trì chúng cũng điều tương tự.
- http://www.liquibase.org là cách tiếp cận tự động ở trên.
- Tôi đã viết trình tạo mã tạo ra các câu lệnh DAL (Lớp truy cập dữ liệu), DDL (Tạo bảng). Chúng tôi đặt chúng kiểm soát nguồn và duy trì ở đó. Tôi nghĩ rằng giải pháp chuyên dụng như liquidibase có thể hoạt động tốt hơn.
Cách tiếp cận này hoạt động tốt nếu có 6. Bạn đặt các câu lệnh DDL, cũng là một mã, trong kiểm soát nguồn và duy trì nó. Không ai sẽ thay đổi Máy chủ thử nghiệm và sản xuất mà không xem xét thích hợp.
Nhược điểm là nếu bạn thực hiện bất kỳ thay đổi nào đối với máy chủ sản xuất hoặc kiểm tra vì bất kỳ lý do gì, sửa lỗi nhanh, thay đổi khóa chính, v.v. Bạn cũng cần cuộn các thay đổi đó cho máy chủ phát triển. Vì máy chủ Phát triển thực sự là SỰ THẬT CỦA BẠN. Không có cách khác xung quanh.
Đây là một cách tiếp cận rất phát triển theo định hướng. Nhưng khi bạn lần đầu tiên phát triển một mô-đun mới, nó hoạt động khá tốt.
Trả lời 2
- nếu 1 và 6 đúng:
Cách tiếp cận tương tự với câu trả lời 1 là duy trì một máy chủ phát triển. Mọi người sử dụng nó thay đổi nó. Hơn khi thời gian đến để cập nhật. Bạn sử dụng một công cụ so sánh cơ sở dữ liệu. Lấy chúng dưới dạng các tập lệnh, đặt nó dưới sự kiểm soát nguồn.
- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)
Sự khác biệt giữa Câu trả lời 1 và Câu trả lời 2 là, trong câu trả lời 1 bạn thu thập các câu lệnh DDL cho toàn bộ cơ sở dữ liệu và bạn lưu trữ chúng. Trong câu trả lời 2 bạn cần lưu trữ mọi phiên bản thay đổi.
- Khởi đầu
- V1
- V2
- V3
- ...
Nếu bạn đặt một cột vào một bảng và sau đó quyết định loại bỏ nó. Các tập lệnh của bạn sẽ hiển thị điều này trong answer2 trong khi ở answer1 bạn sẽ chỉ thấy phiên bản cuối cùng. Và bạn cần so sánh V2 và V1 để thấy sự khác biệt. Cá nhân tôi thích câu trả lời 1 hơn vì tôi có thể dễ dàng so sánh Start và V3, V1 và V3. Trong answer2, tôi cần tìm kiếm tất cả các thay đổi. Ngoài ra trong câu trả lời 2 tập lệnh trong kiểm soát nguồn có xu hướng là một vụ nổ lớn, kịch bản phức tạp. Khó tìm thông tin.
Trả lời 3
Nếu 3 đúng. Lưu ý rằng trong tình huống này, bạn không có ràng buộc 6, nghĩa là: bạn không có máy chủ Phát triển, Kiểm tra, Sản phẩm. Chỉ có máy chủ sản xuất. Bạn có thể sử dụng trình kích hoạt DDL để ghi lại những thay đổi đã được thực hiện. Điều này chủ yếu được sử dụng để ngăn cản mọi người lạm dụng các khoản trợ cấp DDL của họ. Nếu bất kỳ vấn đề xảy ra, bạn có thể tìm thấy trách nhiệm. Để làm việc này, mọi người nên kết nối với tài khoản người dùng của họ và tài khoản Ứng dụng không nên có bất kỳ khoản trợ cấp DDL nào. Vì mọi nhà phát triển đều biết tài khoản Ứng dụng và có thể sử dụng nó.
Trả lời 4
Nếu bạn có 3 và 5. Lưu ý rằng trong tình huống này, bạn không có ràng buộc 6, đó là: bạn không có máy chủ Phát triển, Kiểm tra, Sản phẩm. Chỉ có máy chủ sản xuất. Thay vì kích hoạt để lưu trữ thay đổi. Bạn sử dụng một công cụ bên ngoài để tìm các thay đổi và lưu trữ các tập lệnh DDL trong điều khiển nguồn.
Nếu những công cụ này có khả năng ghi lại những người đã thực hiện thay đổi, nó sẽ hữu ích. Lưu ý rằng trong giải pháp này, bạn mất thêm DDL được thực hiện trong các khoảng thời gian.