Bắt đầu với phiên bản mysql schemata mà không cần quá mức. Giải pháp tốt?

Question

Tôi đã đến điểm mà tôi nhận ra rằng tôi phải bắt đầu phiên bản sơ đồ cơ sở dữ liệu của tôi và thay đổi. Tôi do đó đọc các bài viết hiện có về SO về chủ đề đó nhưng tôi không chắc chắn làm thế nào để tiến hành.

Tôi về cơ bản là một công ty một người và cách đây không lâu tôi thậm chí không sử dụng kiểm soát phiên bản cho mã của mình. Tôi đang trên một môi trường cửa sổ, bằng cách sử dụng Aptana (IDE) và SVN (với Rùa). Tôi làm việc trên các dự án PHP/mysql.

Cách hiệu quả và đầy đủ (không có quá mức) để phiên bản sơ đồ cơ sở dữ liệu của tôi là gì?

Tôi có một freelancer hoặc hai trong một số dự án nhưng tôi không mong đợi nhiều phân nhánh và hợp nhất đang diễn ra. Vì vậy, về cơ bản tôi muốn theo dõi các schemata đồng thời để sửa đổi mã của tôi.

[sửa] giải pháp tạm thời: cho thời điểm tôi quyết định tôi sẽ tạo một giản đồ kết hợp với dữ liệu ban đầu cần thiết bất cứ khi nào tôi cam kết thẻ (phiên bản ổn định). Điều đó dường như là đủ cho tôi ở giai đoạn hiện tại. [/ Edit]

[edit2] plus Tôi hiện đang sử dụng tệp thứ ba có tên là increments.sql, nơi tôi đặt tất cả các thay đổi có ngày, v.v. giúp dễ dàng theo dõi lịch sử thay đổi trong một tệp. theo thời gian, tôi tích hợp các thay đổi vào hai tệp khác và trống rỗng increments.sql [/ edit]

Answer 1

Tôi nghĩ câu hỏi này xứng đáng là câu trả lời hiện đại vì vậy tôi sẽ tự cung cấp. Khi tôi viết câu hỏi vào năm 2009, tôi không nghĩ rằng Phinx đã tồn tại và chắc chắn là Laravel không có. Ngày nay, câu trả lời cho câu hỏi này rất rõ ràng: Viết kịch bản di chuyển DB gia tăng, mỗi tập lệnh có up và phương pháp down và chạy tất cả các tập lệnh hoặc đồng bằng của chúng khi cài đặt hoặc cập nhật ứng dụng của bạn. Và rõ ràng là thêm các kịch bản di trú vào VCS của bạn.

Như đã đề cập ở phần đầu, có những công cụ tuyệt vời hiện nay trong thế giới PHP giúp bạn dễ dàng quản lý việc di chuyển của mình. Laravel có tích hợp DB di trú bao gồm các lệnh shell tương ứng. Mọi người khác đều có một giải pháp độc lập mạnh mẽ về khuôn khổ tương tự với Phinx.

Cả hai di chuyển Artisan (Laravel) và Phinx đều hoạt động tương tự. Đối với mọi thay đổi trong DB, hãy tạo một di chuyển mới, sử dụng SQL đơn giản hoặc trình tạo truy vấn được xây dựng sẵn để viết các phương thức lên và xuống và chạy trả lời artisan migrate. phinx migrate trong bảng điều khiển.

Answer 2

Cách đơn giản cho một công ty nhỏ: kết xuất cơ sở dữ liệu của bạn sang SQL và thêm nó vào kho lưu trữ của bạn. Sau đó, mỗi khi bạn thay đổi một cái gì đó, hãy thêm các thay đổi trong tệp kết xuất.

Sau đó, bạn có thể sử dụng khác biệt để xem các thay đổi giữa các phiên bản, chưa kể có nhận xét giải thích các thay đổi của bạn. Điều này cũng sẽ làm cho bạn hầu như miễn dịch với các nâng cấp MySQL.

Một nhược điểm mà tôi đã thấy là bạn phải nhớ tự thêm SQL vào tệp dumpfile của mình. Bạn có thể rèn luyện bản thân để luôn nhớ, nhưng hãy cẩn thận nếu bạn làm việc với người khác. Thiếu một bản cập nhật có thể là một nỗi đau sau này.

Điều này có thể được giảm nhẹ bằng cách tạo ra một số kịch bản phức tạp để làm điều đó cho bạn khi gửi subversion nhưng nó là một chút nhiều cho một hiển thị một người đàn ông.

Chỉnh sửa: Trong năm đã trôi qua kể từ câu trả lời này, tôi đã phải triển khai sơ đồ phiên bản cho MySQL cho một nhóm nhỏ. Thêm từng thay đổi theo cách thủ công được xem là giải pháp rườm rà, giống như đã được đề cập trong các nhận xét, vì vậy chúng tôi đã bỏ qua cơ sở dữ liệu và thêm tệp đó vào kiểm soát phiên bản.

Điều chúng tôi nhận thấy là dữ liệu thử nghiệm đã kết thúc trong bãi chứa và khiến việc tìm ra những gì đã thay đổi rất khó khăn. Điều này có thể được giải quyết bằng cách bán phá giá lược đồ, nhưng điều này là không thể đối với các dự án của chúng ta vì các ứng dụng của chúng ta phụ thuộc vào một số dữ liệu nhất định trong cơ sở dữ liệu để hoạt động. Cuối cùng, chúng tôi quay trở lại để tự thêm các thay đổi vào kết xuất cơ sở dữ liệu.

Đây không chỉ là giải pháp đơn giản nhất mà còn giải quyết được một số vấn đề nhất định mà một số phiên bản MySQL có với việc xuất/nhập. Thông thường chúng tôi sẽ phải đổ cơ sở dữ liệu phát triển, xóa mọi dữ liệu thử nghiệm, mục nhập nhật ký, v.v., xóa/thay đổi các tên nhất định khi có thể áp dụng và chỉ sau đó mới có thể tạo cơ sở dữ liệu sản xuất. Bằng cách thêm các thay đổi theo cách thủ công, chúng tôi có thể kiểm soát chính xác những gì sẽ kết thúc trong sản xuất, một chút tại một thời điểm, để cuối cùng mọi thứ đã sẵn sàng và chuyển sang môi trường sản xuất là không đau nhất có thể.

Answer 3

Làm thế nào về versioning tập tin được tạo ra bằng cách làm này:

mysqldump --no-data database > database.sql 

Answer 4

Nơi tôi làm việc chúng ta có một cài đặt kịch bản cho mỗi phiên bản mới của ứng dụng đó có sql chúng ta cần phải chạy để nâng cấp. Điều này hoạt động tốt đủ cho 6 nhà phát triển với một số phân nhánh cho bản phát hành bảo trì. Chúng tôi đang xem xét chuyển sang Tự động vá http://autopatch.sourceforge.net/ để xử lý các bản vá để áp dụng cho bất kỳ cơ sở dữ liệu nào bạn đang nâng cấp. Dường như có thể có một số biến chứng nhỏ xử lý phân nhánh với bản vá tự động, nhưng nó không có vẻ như đó sẽ là một vấn đề cho bạn.

Answer 5

tôi muốn đoán, một tập tin thực thi như thế này nên thực hiện công việc (không cố gắng cứng rắn) ...

mysqldump --no-data -ufoo -pbar dbname > path/to/app/schema.sql
svn commit path/to/app/schema.sql

chỉ cần chạy tập tin thực thi sau khi thay đổi schema , hoặc để một cron/scheduler làm điều đó (nhưng tôi không biết ... tôi nghĩ, cam kết làm việc nếu chỉ các dấu thời gian thay đổi, ngay cả khi nội dung là như nhau. không biết nếu đó sẽ là một vấn đề.)

Answer 6

Ideea chính là có thư mục có cấu trúc này trong bạn dự án r cơ sở đường

/__DB 
—-/changesets 
——–/1123 
—-/data 
—-/tables 

Bây giờ người toàn bộ điều hoạt động là bạn có 3 thư mục: Bàn Giữ bàn tạo truy vấn. Tôi khuyên bạn nên sử dụng đặt tên "table_name.sql".

Dữ liệu Giữ truy vấn dữ liệu chèn bảng. Tôi khuyên bạn nên sử dụng cùng một tên "table_name.sql". Lưu ý: Không phải tất cả các bảng đều cần một tệp dữ liệu, bạn sẽ chỉ thêm các tệp cần dữ liệu ban đầu này vào cài đặt dự án.

changesets Đây là thư mục chính bạn sẽ làm việc cùng. Điều này giữ các bộ thay đổi được thực hiện cho cấu trúc ban đầu. Điều này thực sự chứa các thư mục với changesets. Ví dụ tôi đã thêm một thư mục 1123 sẽ chứa các sửa đổi được thực hiện trong bản sửa đổi 1123 (số này là từ kiểm soát nguồn mã của bạn) và có thể chứa một hoặc nhiều tệp sql.

Tôi muốn thêm chúng được nhóm vào các bảng với tên xx_tablename.sql - xx là một số cho biết thứ tự chúng cần được chạy, vì đôi khi bạn cần sửa đổi được điều chỉnh theo một thứ tự nhất định.

Lưu ý: Khi bạn sửa đổi một bảng, bạn cũng có thêm những thay đổi để bàn và các file dữ liệu ... bởi vì đó là file s sẽ được sử dụng để làm một tươi cài đặt.

Đây là ideea chính.

để biết thêm chi tiết bạn có thể kiểm tra điều này blog post

Answer 7

Tại công ty chúng tôi đã làm nó theo cách này:

Chúng tôi đặt tất cả các bảng/đối tượng db trong tập tin riêng của họ, như tbl_Foo.sql.Các tập tin chứa một số "phụ tùng" mà được giới hạn với

-- part: create 

nơi create chỉ là một xác định mô tả cho một phần nhất định, các tập tin trông giống như:

-- part: create 
IF not exists ... 
CREATE TABLE tbl_Foo ... 
-- part: addtimestamp 
IF not exists ... 
BEGIN 
    ALTER TABLE ... 
END 

Sau đó, chúng ta có một tập tin xml rằng tài liệu tham khảo mọi phần mà chúng ta muốn thực hiện khi chúng ta cập nhật cơ sở dữ liệu sang lược đồ mới. Nó trông khá nhiều như thế này:

<playlist> 
    <classes> 
    <class name="table" desc="Table creation" /> 
    <class name="schema" desc="Table optimization" /> 
    </classes> 
    <dbschema> 
     <steps db="a_database"> 
     <step file="tbl_Foo.sql" part="create" class="table" /> 
     <step file="tbl_Bar.sql" part="create" class="table" /> 
     </steps> 
     <steps db="a_database"> 
     <step file="tbl_Foo.sql" part="addtimestamp" class="schema" /> 
     </steps> 
    </dbschema>   
</playlist> 

Phần <classes/> nếu cho GUI, và <dbschema/> với <steps/> là để phân vùng thay đổi. <step/>: s được thực hiện tuần tự. Chúng tôi có một số thực thể khác, như sqlclr để thực hiện những việc khác nhau như triển khai tệp nhị phân, nhưng đó là khá nhiều. Tất nhiên chúng tôi có một thành phần mà có tập tin danh sách nhạc đó và một đối tượng tài nguyên/hệ thống tập tin mà chéo qua danh sách phát và đưa ra các phần mong muốn và sau đó chạy chúng như là admin trên cơ sở dữ liệu. Quay lại đầu trang |

Vì "phần" trong .sql được viết để chúng có thể được thực hiện trên bất kỳ phiên bản nào của DB, chúng tôi có thể chạy tất cả các phần trên mọi phiên bản cũ hơn/cũ hơn của DB và sửa đổi nó thành hiện tại. Tất nhiên có một số trường hợp máy chủ SQL phân tích cú pháp tên cột "sớm" và chúng tôi phải sửa đổi phần sau để trở thành exec_sql s, nhưng nó không xảy ra thường xuyên.

Answer 8

Tôi làm điều gì đó tương tự như Manos, ngoại trừ tôi có một tập tin 'master' (master.sql) mà tôi cập nhật với một số quy luật (mỗi 2 tháng một lần). Sau đó, đối với mỗi thay đổi tôi xây dựng một phiên bản có tên .sql tập tin với những thay đổi. Bằng cách này, tôi có thể bắt đầu với master.sql và thêm mỗi phiên bản có tên .sql file cho đến khi tôi nhận được phiên bản hiện tại và tôi có thể cập nhật các máy khách bằng cách sử dụng phiên bản có tên .sql files để làm cho mọi việc trở nên đơn giản hơn.

Answer 9

Hãy xem SchemaSync. Nó sẽ tạo bản vá và hoàn nguyên tập lệnh (tệp .sql) cần thiết để di chuyển và phiên bản lược đồ cơ sở dữ liệu của bạn theo thời gian. Đó là một tiện ích dòng lệnh cho MySQL là ngôn ngữ và khung độc lập.

Answer 10

Một vài tháng trước, tôi đã tìm kiếm công cụ để phiên bản lược đồ MySQL. Tôi đã tìm thấy nhiều công cụ hữu ích, như di chuyển Doctrine, di trú RoR, một số công cụ được viết bằng Java và Python.

Nhưng không ai trong số họ hài lòng với yêu cầu của tôi.

yêu cầu của tôi:

1. Không có yêu cầu, loại trừ PHP và MySQL
2. Không có tập tin cấu hình lược đồ, như schema.yml trong Học thuyết
3. Có khả năng đọc sơ đồ hiện tại từ kết nối và tạo kịch bản di dân mới, hơn là biểu diễn lược đồ giống hệt nhau trong các cài đặt ứng dụng khác.

Tôi bắt đầu viết công cụ di chuyển của mình và hôm nay tôi có phiên bản beta.

Hãy thử, nếu bạn quan tâm đến chủ đề này. Vui lòng gửi cho tôi các yêu cầu và báo cáo lỗi trong tương lai.

Mã nguồn: bitbucket.org/idler/mmp/src Tổng quan bằng tiếng Anh: bitbucket.org/idler/mmp/wiki/Trang chủ Tổng quan bằng tiếng Nga: antonoff.info/development/mysql-migration-with-php-project

Answer 11

Giải pháp của chúng tôi là MySQL Workbench. Chúng tôi thường xuyên thiết kế lại Cơ sở dữ liệu hiện có thành một Mô hình với số phiên bản thích hợp. Sau đó, bạn có thể dễ dàng thực hiện các Khác biệt giữa các phiên bản nếu cần. Ngoài ra, chúng tôi có được Sơ đồ EER tốt đẹp, v.v.