Bạn có sử dụng kiểm soát nguồn cho các mục cơ sở dữ liệu của bạn? [đóng cửa]

Tôi cảm thấy rằng cửa hàng của tôi có một lỗ hổng vì chúng tôi không có một quy trình vững chắc để thay đổi lược đồ cơ sở dữ liệu của chúng tôi. Chúng tôi thực hiện rất nhiều bản sao lưu để chúng tôi ít nhiều được bảo hiểm, nhưng thực tế là dựa vào tuyến phòng thủ cuối cùng của bạn theo cách này.

Đáng ngạc nhiên, đây dường như là một chủ đề phổ biến. Nhiều cửa hàng tôi đã nói để bỏ qua vấn đề này vì cơ sở dữ liệu của họ không thay đổi thường xuyên và về cơ bản họ chỉ cố gắng tỉ mỉ.

Tuy nhiên, tôi biết câu chuyện đó diễn ra như thế nào. Đó chỉ là vấn đề thời gian trước khi mọi thứ xếp hàng sai và thiếu một cái gì đó.

Có thực hành tốt nhất cho việc này? Một số chiến lược đã làm việc cho bạn là gì?

Phải đọc Nhận cơ sở dữ liệu của bạn dưới sự kiểm soát phiên bản . Kiểm tra loạt bài viết của K. Scott Allen.

Khi nói đến kiểm soát phiên bản, cơ sở dữ liệu thường là công dân hạng hai hoặc thậm chí hạng ba. Từ những gì tôi đã thấy, các nhóm sẽ không bao giờ nghĩ đến việc viết mã mà không kiểm soát phiên bản trong một triệu năm - và đúng như vậy-- bằng cách nào đó có thể hoàn toàn không biết đến nhu cầu kiểm soát phiên bản xung quanh cơ sở dữ liệu quan trọng mà ứng dụng của họ dựa vào. Tôi không biết làm thế nào bạn có thể gọi cho mình một kỹ sư phần mềm và giữ khuôn mặt thẳng thắn khi cơ sở dữ liệu của bạn không nằm dưới cùng mức độ kiểm soát nguồn nghiêm ngặt như phần còn lại của mã. Đừng để điều này xảy ra với bạn. Nhận cơ sở dữ liệu của bạn dưới sự kiểm soát phiên bản.

Các cơ sở dữ liệu? Không

Các tập lệnh tạo ra chúng, bao gồm chèn dữ liệu tĩnh, các thủ tục được lưu trữ và tương tự; tất nhiên. Chúng là các tệp văn bản, chúng được bao gồm trong dự án và được kiểm tra trong và ngoài như mọi thứ khác.

Tất nhiên trong một thế giới lý tưởng, công cụ quản lý cơ sở dữ liệu của bạn sẽ làm điều này; nhưng bạn chỉ cần có kỷ luật về nó.

Tôi hoàn toàn thích di chuyển Rails ActiveRecord. Nó trừu tượng hóa tập lệnh DML thành ruby, sau đó có thể dễ dàng trở thành phiên bản trong kho lưu trữ nguồn của bạn.

Tuy nhiên, với một chút công việc, bạn có thể làm điều tương tự. Mọi thay đổi DDL (ALTER TABLE, v.v.) có thể được lưu trữ trong các tệp văn bản. Giữ một hệ thống đánh số (hoặc dấu ngày) cho tên tệp và áp dụng chúng theo thứ tự.

Rails cũng có bảng 'phiên bản' trong DB theo dõi quá trình di chuyển được áp dụng cuối cùng. Bạn có thể làm tương tự dễ dàng.

Kiểm tra LiquiBase để quản lý các thay đổi cơ sở dữ liệu bằng cách sử dụng kiểm soát nguồn.

Bạn không bao giờ nên đăng nhập và bắt đầu nhập các lệnh "ALTER TABLE" để thay đổi cơ sở dữ liệu sản xuất. Dự án tôi đang có cơ sở dữ liệu trên mọi trang web của khách hàng và do đó, mọi thay đổi đối với cơ sở dữ liệu được thực hiện ở hai nơi, một tệp kết xuất được sử dụng để tạo cơ sở dữ liệu mới trên trang web của khách hàng mới và tệp cập nhật được chạy trên mỗi bản cập nhật kiểm tra số phiên bản cơ sở dữ liệu hiện tại của bạn so với số cao nhất trong tệp và cập nhật cơ sở dữ liệu của bạn. Vì vậy, ví dụ, cặp cập nhật cuối cùng:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Tôi chắc chắn có một cách tốt hơn để làm điều này, nhưng nó đã làm việc cho tôi cho đến nay.

Đúng. Mã là mã. Nguyên tắc nhỏ của tôi là tôi cần có khả năng xây dựng và triển khai ứng dụng từ đầu , mà không cần nhìn vào một cỗ máy phát triển hay sản xuất.

Cách thực hành tốt nhất tôi đã thấy là tạo một tập lệnh xây dựng để loại bỏ và xây dựng lại cơ sở dữ liệu của bạn trên một máy chủ dàn dựng. Mỗi lần lặp được cung cấp một thư mục để thay đổi cơ sở dữ liệu, tất cả các thay đổi được viết theo kịch bản với "Thả ... Tạo". Bằng cách này, bạn có thể quay lại phiên bản cũ hơn bất cứ lúc nào bằng cách trỏ bản dựng vào thư mục bạn muốn phiên bản.

Tôi tin rằng điều này đã được thực hiện với NaNt / CruiseControl.

CÓ, tôi nghĩ điều quan trọng là phiên bản cơ sở dữ liệu của bạn. Không phải dữ liệu, nhưng lược đồ cho chắc chắn.

Trong Ruby On Rails, điều này được xử lý bởi khung với "di chuyển". Bất cứ khi nào bạn thay đổi db, bạn tạo một tập lệnh áp dụng các thay đổi và kiểm tra nó thành kiểm soát nguồn.

Cửa hàng của tôi thích ý tưởng đó đến nỗi chúng tôi đã thêm chức năng vào bản dựng dựa trên Java của chúng tôi bằng cách sử dụng các tập lệnh shell và Ant. Chúng tôi tích hợp quy trình vào thói quen triển khai của chúng tôi. Sẽ khá dễ dàng để viết các tập lệnh để làm điều tương tự trong các khung công tác khác không hỗ trợ phiên bản DB ngoài luồng.

Các dự án cơ sở dữ liệu mới trong Visual Studio cung cấp kiểm soát nguồn và thay đổi tập lệnh.

Họ có một công cụ tuyệt vời để so sánh các cơ sở dữ liệu và có thể tạo ra một kịch bản chuyển đổi lược đồ của cái này sang cái khác hoặc cập nhật dữ liệu trong cái này để khớp với cái kia.

Lược đồ db được "băm nhỏ" để tạo ra nhiều, rất nhiều tệp .sql nhỏ, mỗi lệnh DDL mô tả DB.

+ tom

Thông tin bổ sung 2008-11-30

Tôi đã sử dụng nó như một nhà phát triển trong năm qua và thực sự thích nó. Nó giúp dễ dàng so sánh công việc phát triển của tôi với sản xuất và tạo tập lệnh để sử dụng cho bản phát hành. Tôi không biết nếu thiếu các tính năng mà các DBA cần cho các dự án "loại doanh nghiệp".

Vì lược đồ được "băm nhỏ" thành các tệp sql, điều khiển nguồn hoạt động tốt.

Một điều đáng chú ý là bạn cần có một suy nghĩ khác khi bạn sử dụng dự án db. Công cụ này có "dự án db" trong VS, chỉ là sql, cộng với cơ sở dữ liệu cục bộ được tạo tự động có lược đồ và một số dữ liệu quản trị khác - nhưng không có dữ liệu ứng dụng nào của bạn, cộng với dev db cục bộ mà bạn sử dụng cho ứng dụng dữ liệu dev làm việc. Bạn hiếm khi nhận thức được db được tạo tự động, nhưng bạn phải biết nó ở đó để bạn có thể để nó một mình :). Db đặc biệt này có thể nhận ra rõ ràng vì nó có Hướng dẫn trong tên của nó,

Dự án VS DB thực hiện tốt công việc tích hợp các thay đổi db mà các thành viên khác trong nhóm đã thực hiện vào dự án / db liên kết cục bộ của bạn. nhưng bạn cần thực hiện thêm bước để so sánh lược đồ dự án với lược đồ dev db cục bộ của bạn và áp dụng các mod. Nó có ý nghĩa, nhưng có vẻ khó xử lúc đầu.

Dự án DB là một công cụ rất mạnh mẽ. Họ không chỉ tạo ra các kịch bản mà có thể áp dụng chúng ngay lập tức. Hãy chắc chắn không phá hủy db sản xuất của bạn với nó. ;)

Tôi thực sự thích các dự án VS DB và tôi hy vọng sẽ sử dụng công cụ này cho tất cả các dự án db của tôi trong tương lai.

+ tom

Yêu cầu các nhóm phát triển sử dụng hệ thống quản lý kiểm soát nguồn cơ sở dữ liệu SQL không phải là viên đạn ma thuật sẽ ngăn chặn các vấn đề xảy ra. Về bản thân, kiểm soát nguồn cơ sở dữ liệu giới thiệu thêm chi phí vì các nhà phát triển được yêu cầu lưu các thay đổi họ đã thực hiện cho một đối tượng trong một tập lệnh SQL riêng biệt, mở máy khách hệ thống kiểm soát nguồn, kiểm tra tệp tập lệnh SQL bằng máy khách và sau đó áp dụng các thay đổi cho cơ sở dữ liệu trực tiếp.

Tôi có thể đề xuất sử dụng bổ trợ SSMS có tên ApexSQL Source Control . Nó cho phép các nhà phát triển dễ dàng ánh xạ các đối tượng cơ sở dữ liệu với hệ thống kiểm soát nguồn thông qua trình hướng dẫn trực tiếp từ SSMS. Bổ trợ bao gồm hỗ trợ cho các hệ thống TFS, Git, Subversion và các hệ thống SC khác. Nó cũng bao gồm hỗ trợ cho việc kiểm soát nguồn dữ liệu tĩnh.

Sau khi tải xuống và cài đặt ApexSQL Source Control, chỉ cần nhấp chuột phải vào cơ sở dữ liệu mà bạn muốn kiểm soát phiên bản và điều hướng đến menu phụ ApexQuery Source Control trong SSMS. Nhấp vào tùy chọn Liên kết cơ sở dữ liệu để kiểm soát nguồn, chọn hệ thống kiểm soát nguồn và mô hình phát triển. Sau đó, bạn sẽ cần cung cấp thông tin đăng nhập và chuỗi kho lưu trữ cho hệ thống kiểm soát nguồn bạn đã chọn.

Bạn có thể đọc bài viết này để biết thêm thông tin: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

Tôi làm bằng cách lưu tập lệnh tạo / cập nhật và tập lệnh tạo mẫu.

Có, chúng tôi làm điều đó bằng cách giữ SQL của chúng tôi như là một phần của bản dựng - chúng tôi giữ DROP.sql, CREATE.sql, USERS.sql, VALUES.sql và phiên bản kiểm soát chúng, để chúng tôi có thể quay lại bất kỳ phiên bản được gắn thẻ nào.

Chúng tôi cũng có các tác vụ ant có thể tạo lại db bất cứ khi nào cần.

Thêm vào đó, SQL sau đó được gắn thẻ cùng với mã nguồn của bạn đi cùng với nó.

Lược đồ thành công nhất mà tôi từng sử dụng trong một dự án đã kết hợp các bản sao lưu và các tệp SQL khác biệt. Về cơ bản, chúng tôi sẽ sao lưu db của chúng tôi sau mỗi lần phát hành và thực hiện kết xuất SQL để chúng tôi có thể tạo một lược đồ trống từ đầu nếu chúng tôi cũng cần. Sau đó, bất cứ khi nào bạn cần để thực hiện thay đổi đối với DB, bạn sẽ thêm một đoạn mã thay đổi vào thư mục sql dưới sự kiểm soát phiên bản. Chúng tôi sẽ luôn đặt tiền tố cho một số thứ tự hoặc ngày vào tên tệp để thay đổi đầu tiên sẽ là một cái gì đó giống như 01_add_created_on_column.sql và tập lệnh tiếp theo sẽ là 02_added_customftimeindex. Máy CI của chúng tôi sẽ kiểm tra những thứ này và chạy chúng tuần tự trên một bản sao mới của db đã được khôi phục từ bản sao lưu.

Chúng tôi cũng đã có một số tập lệnh tại chỗ mà các nhà phát triển có thể sử dụng để khởi tạo lại db cục bộ của họ sang phiên bản hiện tại bằng một lệnh duy nhất.

Chúng tôi kiểm soát nguồn tất cả các đối tượng tạo cơ sở dữ liệu của chúng tôi. Và chỉ để giữ cho các nhà phát triển trung thực (vì bạn có thể tạo các đối tượng mà không có họ trong Kiểm soát nguồn), dbas của chúng tôi định kỳ tìm kiếm bất cứ thứ gì không có trong kiểm soát nguồn và nếu họ tìm thấy bất cứ điều gì, họ sẽ bỏ nó mà không hỏi liệu có ổn không.

Tôi sử dụng SchemaBank để kiểm soát phiên bản tất cả các thay đổi lược đồ cơ sở dữ liệu của mình:

• từ ngày 1, tôi nhập kết xuất lược đồ db của mình vào nó
• tôi bắt đầu thay đổi thiết kế lược đồ của mình bằng trình duyệt web (vì chúng dựa trên SaaS / dựa trên đám mây)
• Khi tôi muốn cập nhật máy chủ db của mình, tôi tạo tập lệnh thay đổi (SQL) từ nó và áp dụng cho db. Trong Schemabank, họ bắt buộc tôi phải cam kết công việc của mình là phiên bản trước khi tôi có thể tạo tập lệnh cập nhật. Tôi thích loại thực hành này để tôi luôn có thể theo dõi lại khi tôi cần.

Quy tắc nhóm của chúng tôi là KHÔNG BAO GIỜ chạm trực tiếp vào máy chủ db mà không lưu trữ công việc thiết kế trước. Nhưng nó xảy ra, ai đó có thể bị cám dỗ để phá vỡ quy tắc, vì thuận tiện. Chúng tôi sẽ nhập kết xuất lược đồ một lần nữa vào schemabank và để nó thực hiện tìm khác biệt và bash ai đó nếu tìm thấy sự khác biệt. Mặc dù chúng tôi có thể tạo các tập lệnh thay đổi từ nó để làm cho thiết kế lược đồ và db của chúng tôi đồng bộ hóa, chúng tôi chỉ ghét điều đó.

Nhân tiện, họ cũng cho phép chúng tôi tạo các nhánh trong cây điều khiển phiên bản để tôi có thể duy trì một nhánh để dàn dựng và một nhánh để sản xuất. Và một cho mã hóa hộp cát.

Một công cụ thiết kế lược đồ dựa trên web khá gọn gàng với kiểm soát phiên bản n quản lý thay đổi.

Tôi có mọi thứ cần thiết để tạo lại DB của mình từ kim loại trần, trừ đi dữ liệu. Tôi chắc chắn có rất nhiều cách để làm điều đó, nhưng tất cả các tập lệnh của tôi và những thứ đó được lưu trữ trong lật đổ và chúng ta có thể xây dựng lại cấu trúc DB và bằng cách kéo tất cả những thứ đó ra khỏi lật đổ và chạy trình cài đặt.

Tôi thường xây dựng một tập lệnh SQL cho mỗi thay đổi tôi thực hiện và một tập lệnh khác để hoàn nguyên các thay đổi đó và giữ các tập lệnh đó dưới sự kiểm soát phiên bản.

Sau đó, chúng tôi có một phương tiện để tạo một cơ sở dữ liệu cập nhật mới theo yêu cầu và có thể dễ dàng di chuyển giữa các phiên bản. Mỗi lần chúng tôi phát hành, chúng tôi gộp các tập lệnh lại với nhau (mất một chút công việc thủ công, nhưng nó thực sự hiếm khi khó ) vì vậy chúng tôi cũng có một bộ tập lệnh có thể chuyển đổi giữa các phiên bản.

Vâng, trước khi bạn nói, điều này rất giống với những thứ mà Rails và những người khác làm, nhưng nó có vẻ hoạt động khá tốt, vì vậy tôi không có vấn đề gì khi thừa nhận rằng tôi đã xấu hổ gỡ bỏ ý tưởng :)

Tôi sử dụng các tập lệnh SQL CREATE được xuất từ ​​MySQL Workbech, sau đó sử dụng chức năng "Xuất SQL ALTER" của chúng. Tôi kết thúc với một loạt các tập lệnh tạo (tất nhiên là được đánh số) và các tập lệnh thay đổi có thể áp dụng các thay đổi giữa chúng.

3.- Xuất tập lệnh ALTER SQL Thông thường bạn sẽ phải viết các câu lệnh ALTER TABLE bằng tay ngay bây giờ, phản ánh các thay đổi bạn đã thực hiện cho mô hình. Nhưng bạn có thể thông minh và để Workbench làm việc chăm chỉ cho bạn. Chỉ cần chọn Tệp -> Xuất -> Chuyển tiếp Kỹ sư SQL ALTER Script Tập từ menu chính.

Điều này sẽ nhắc bạn chỉ định tệp SQL CREATE mà mô hình hiện tại sẽ được so sánh với.

Chọn tập lệnh SQL CREATE từ bước 1. Công cụ sau đó sẽ tạo tập lệnh ALTER TABLE cho bạn và bạn có thể thực thi tập lệnh này dựa trên cơ sở dữ liệu của mình để cập nhật tập lệnh.

Bạn có thể thực hiện việc này bằng Trình duyệt truy vấn MySQL hoặc máy khách mysql.Voila! Mô hình và cơ sở dữ liệu của bạn hiện đã được đồng bộ hóa!

Nguồn: MySQL Workbench Community Edition: Hướng dẫn đồng bộ hóa lược đồ

Tất cả các tập lệnh này tất nhiên là bên trong dưới sự kiểm soát phiên bản.

Vâng, luôn luôn. Bạn sẽ có thể tạo lại cấu trúc cơ sở dữ liệu sản xuất của mình với một bộ dữ liệu mẫu hữu ích bất cứ khi nào cần. Nếu bạn không, theo thời gian, những thay đổi nhỏ để giữ cho mọi thứ chạy bị lãng quên thì một ngày nào đó bạn bị cắn, thời gian lớn. Bảo hiểm của nó mà bạn có thể không nghĩ rằng bạn cần nhưng ngày bạn làm điều đó đáng giá gấp 10 lần!

Đã có rất nhiều cuộc thảo luận về chính mô hình cơ sở dữ liệu, nhưng chúng tôi cũng giữ dữ liệu cần thiết trong các tệp .Query.

Ví dụ, để hữu ích, ứng dụng của bạn có thể cần điều này trong phần cài đặt:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

Chúng tôi sẽ có một tập tin được gọi là currency.sqllật đổ. Là một bước thủ công trong quy trình xây dựng, chúng tôi so sánh loại tiền tệ trước đó với loại tiền mới nhất và viết một kịch bản nâng cấp.

Chúng tôi phiên bản và kiểm soát nguồn mọi thứ xung quanh cơ sở dữ liệu của chúng tôi:

• DDL (tạo và thay đổi)
• DML (dữ liệu tham khảo, mã, v.v.)
• Thay đổi Mô hình Dữ liệu (sử dụng ERwin hoặc ER / Studio)
• Thay đổi cấu hình cơ sở dữ liệu (quyền, đối tượng bảo mật, thay đổi cấu hình chung)

Chúng tôi thực hiện tất cả điều này với các công việc tự động bằng Trình quản lý thay đổi và một số tập lệnh tùy chỉnh. Chúng tôi có Trình quản lý thay đổi theo dõi những thay đổi này và thông báo khi chúng được thực hiện.

Tôi tin rằng mọi DB nên được kiểm soát nguồn và các nhà phát triển nên có một cách dễ dàng để tạo cơ sở dữ liệu cục bộ của họ từ đầu. Lấy cảm hứng từ Visual Studio cho các chuyên gia cơ sở dữ liệu, tôi đã tạo ra một công cụ nguồn mở để kịch bản các cơ sở dữ liệu MS SQL, và cung cấp và cách dễ dàng triển khai chúng cho công cụ DB cục bộ của bạn. Hãy thử http://dbsourcetools.codeplex.com/ . Hãy vui vẻ, - Nathan.

Nếu Cơ sở dữ liệu của bạn là SQL Server, chúng tôi có thể có giải pháp bạn đang tìm kiếm. SQL Source Control 1.0 hiện đã được phát hành.

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

Điều này tích hợp vào SSMS và cung cấp chất kết dính giữa các đối tượng cơ sở dữ liệu và VCS của bạn. Việc 'scripting out' diễn ra một cách minh bạch (nó sử dụng công cụ So sánh SQL dưới mui xe), điều này sẽ khiến cho việc sử dụng nó trở nên đơn giản đến mức các nhà phát triển sẽ không nản lòng khi áp dụng quy trình.

Một giải pháp Visual Studio thay thế là ReadyRoll , được triển khai như một kiểu con của Dự án cơ sở dữ liệu SSDT. Điều này có một cách tiếp cận theo hướng di chuyển, phù hợp hơn với các yêu cầu tự động hóa của các nhóm DevOps.

Tôi kiểm soát nguồn lược đồ cơ sở dữ liệu bằng cách viết ra tất cả các đối tượng (định nghĩa bảng, chỉ mục, thủ tục được lưu trữ, v.v.). Nhưng, đối với dữ liệu, chỉ cần dựa vào các bản sao lưu thông thường. Điều này đảm bảo rằng tất cả các thay đổi cấu trúc được ghi lại với lịch sử sửa đổi phù hợp, nhưng không gây gánh nặng cho cơ sở dữ liệu mỗi khi dữ liệu thay đổi.

Tại doanh nghiệp của chúng tôi, chúng tôi sử dụng các kịch bản thay đổi cơ sở dữ liệu. Khi tập lệnh được chạy, tên của nó được lưu trữ trong cơ sở dữ liệu và sẽ không chạy lại, trừ khi hàng đó bị xóa. Các tập lệnh được đặt tên dựa trên ngày, thời gian và nhánh mã, do đó việc thực thi được kiểm soát là có thể.

Rất nhiều và rất nhiều thử nghiệm được thực hiện trước khi các kịch bản được chạy trong môi trường sống, do đó, "oopsies" chỉ xảy ra, nói chung, trên cơ sở dữ liệu phát triển.

Chúng tôi đang trong quá trình chuyển tất cả các cơ sở dữ liệu sang kiểm soát nguồn. Chúng tôi đang sử dụng sqlcompare để kịch bản ra cơ sở dữ liệu (không may là một tính năng phiên bản chuyên nghiệp) và đưa kết quả đó vào SVN.

Thành công của việc thực hiện của bạn sẽ phụ thuộc rất nhiều vào văn hóa và thực tiễn của tổ chức của bạn. Mọi người ở đây tin vào việc tạo ra một cơ sở dữ liệu cho mỗi ứng dụng. Có một bộ cơ sở dữ liệu phổ biến được sử dụng bởi hầu hết các ứng dụng cũng gây ra rất nhiều phụ thuộc giữa các cơ sở dữ liệu (một số trong số chúng là thông tư). Việc đưa các lược đồ cơ sở dữ liệu vào kiểm soát nguồn rất khó khăn vì các phụ thuộc liên cơ sở dữ liệu mà các hệ thống của chúng tôi có.

Điều may mắn nhất đối với bạn, bạn càng dùng thử sớm thì bạn càng sớm giải quyết được các vấn đề của mình.

Tôi đã sử dụng công cụ dbdeploy từ Th ThinkWorks tại http://dbdeploy.com/ . Nó khuyến khích việc sử dụng các tập lệnh di chuyển. Mỗi bản phát hành, chúng tôi hợp nhất các tập lệnh thay đổi thành một tệp để dễ hiểu và cho phép các DBA 'ban phước' cho các thay đổi.

Điều này cũng luôn gây phiền toái lớn cho tôi - có vẻ như quá dễ dàng để thực hiện thay đổi nhanh chóng cho cơ sở dữ liệu phát triển của bạn, lưu nó (quên lưu tập lệnh thay đổi), và sau đó bạn bị mắc kẹt. Bạn có thể hoàn tác những gì bạn vừa làm và làm lại nó để tạo tập lệnh thay đổi hoặc viết nó từ đầu nếu bạn cũng muốn, mặc dù đó là rất nhiều thời gian dành cho việc viết kịch bản.

Một công cụ mà tôi đã sử dụng trong quá khứ đã giúp một số công cụ này là SQL Delta. Nó sẽ cho bạn thấy sự khác biệt giữa hai cơ sở dữ liệu (máy chủ SQL / Oracle tôi tin) và tạo ra tất cả các tập lệnh thay đổi cần thiết để di chuyển A-> B. Một điều tuyệt vời nữa là nó cho thấy tất cả sự khác biệt giữa nội dung cơ sở dữ liệu giữa DB sản xuất (hoặc thử nghiệm) và DB phát triển của bạn. Do ngày càng có nhiều ứng dụng lưu trữ cấu hình và trạng thái quan trọng đối với việc thực thi chúng trong các bảng cơ sở dữ liệu, việc thay đổi các tập lệnh loại bỏ, thêm và thay đổi các hàng thích hợp có thể là một nỗi đau thực sự. SQL Delta hiển thị các hàng trong cơ sở dữ liệu giống như chúng sẽ tìm trong công cụ Diff - đã thay đổi, thêm, xóa.

Một công cụ tuyệt vời. Đây là liên kết: http://www.sqldelta.com/

RedGate thật tuyệt vời, chúng tôi tạo ra các ảnh chụp nhanh mới khi các thay đổi cơ sở dữ liệu được thực hiện (một tệp nhị phân nhỏ) và giữ tệp đó trong các dự án dưới dạng tài nguyên. Bất cứ khi nào chúng tôi cần cập nhật cơ sở dữ liệu, chúng tôi sử dụng bộ công cụ của RedGate để cập nhật cơ sở dữ liệu, cũng như có thể tạo cơ sở dữ liệu mới từ cơ sở dữ liệu trống.

RedGate cũng tạo ảnh chụp nhanh Dữ liệu, trong khi cá nhân tôi chưa từng làm việc với họ, họ cũng mạnh mẽ như vậy.

FYI Điều này cũng đã được đưa ra vài ngày trước bởi Dana ... Các thủ tục lưu trữ / lược đồ DB trong kiểm soát nguồn