Apakah ada sistem kontrol versi untuk perubahan struktur database?

Saya sering mengalami masalah berikut.

Saya mengerjakan beberapa perubahan pada proyek yang membutuhkan tabel atau kolom baru dalam database. Saya membuat modifikasi database dan melanjutkan pekerjaan saya. Biasanya, saya ingat untuk menuliskan perubahan sehingga dapat direplikasi di sistem langsung. Namun, saya tidak selalu ingat apa yang telah saya ubah dan saya tidak selalu ingat untuk menuliskannya.

Jadi, saya melakukan push ke sistem live dan mendapatkan error yang besar dan jelas bahwa tidak ada NewColumnX, ugh.

Terlepas dari kenyataan bahwa ini mungkin bukan praktik terbaik untuk situasi ini, apakah ada sistem kontrol versi untuk database? Saya tidak peduli dengan teknologi database tertentu. Saya hanya ingin tahu apakah ada. Jika kebetulan bekerja dengan MS SQL Server, maka bagus.

Di Ruby on Rails, ada konsep migrasi - skrip cepat untuk mengubah database.

Anda membuat file migrasi, yang memiliki aturan untuk meningkatkan versi db (seperti menambahkan kolom) dan aturan untuk menurunkan versi (seperti menghapus kolom). Setiap migrasi diberi nomor, dan sebuah tabel melacak versi db Anda saat ini.

Untuk bermigrasi , Anda menjalankan perintah bernama "db: migrate" yang melihat versi Anda dan menerapkan skrip yang diperlukan. Anda dapat bermigrasi ke bawah dengan cara yang sama.

Skrip migrasi itu sendiri disimpan dalam sistem kontrol versi - setiap kali Anda mengubah database, Anda memeriksa skrip baru, dan setiap pengembang dapat menerapkannya untuk membawa db lokal mereka ke versi terbaru.

Saya agak jadul, karena saya menggunakan file sumber untuk membuat database. Sebenarnya ada 2 file - project-database.sql dan project-update.sql - yang pertama untuk skema dan data persisten, dan yang kedua untuk modifikasi. Tentu saja, keduanya berada di bawah kendali sumber.

Ketika database berubah, pertama-tama saya memperbarui skema utama di project-database.sql, lalu salin info yang relevan ke project-update.sql, misalnya pernyataan ALTER TABLE. Saya kemudian dapat menerapkan pembaruan ke database pengembangan, menguji, mengulang hingga selesai dengan baik. Kemudian, periksa file, uji lagi, dan terapkan ke produksi.

Juga, saya biasanya memiliki tabel di db - Config - seperti:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

Kemudian, saya menambahkan yang berikut ini ke bagian pembaruan:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

Satu- db_versionsatunya akan berubah ketika database dibuat ulang, dan db_revisionmemberi saya indikasi seberapa jauh db dari baseline.

Saya dapat menyimpan pembaruan di file terpisah mereka sendiri, tetapi saya memilih untuk menggabungkan semuanya dan menggunakan potong & tempel untuk mengekstrak bagian yang relevan. Sedikit lebih banyak pekerjaan rumah beres, yaitu, hapus ':' dari $ Revisi 1.1 $ untuk membekukannya.

MyBatis (sebelumnya iBatis ) memiliki migrasi skema , alat untuk digunakan pada baris perintah. Itu ditulis dalam java meskipun dapat digunakan dengan proyek apa pun.

Untuk mencapai praktik manajemen perubahan database yang baik, kita perlu mengidentifikasi beberapa tujuan utama. Dengan demikian, Sistem Migrasi Skema MyBatis (atau disingkat Migrasi MyBatis) berupaya untuk:

• Bekerja dengan database apa pun, baru atau yang sudah ada
• Memanfaatkan sistem kendali sumber (mis. Subversion)
• Memungkinkan pengembang atau tim serentak untuk bekerja secara mandiri
• Izinkan konflik sangat terlihat dan mudah dikelola
• Izinkan migrasi maju dan mundur (berevolusi, berpindah masing-masing)
• Jadikan status database saat ini mudah diakses dan dipahami
• Aktifkan migrasi terlepas dari hak akses atau birokrasi
• Bekerja dengan metodologi apa pun
• Mendorong praktik yang baik dan konsisten

Redgate memiliki produk yang disebut Kontrol Sumber SQL . Ini terintegrasi dengan TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce, dan Git.

Saya sangat merekomendasikan SQL delta . Saya hanya menggunakannya untuk menghasilkan skrip diff ketika saya selesai mengkodekan fitur saya dan memeriksa skrip tersebut ke alat kontrol sumber saya (Mercurial :))

Mereka memiliki versi SQL server & Oracle.

Saya heran bahwa tidak ada yang menyebutkan alat open source liquibase yang berbasis Java dan harus bekerja untuk hampir setiap database yang mendukung jdbc. Dibandingkan dengan rails, ia menggunakan xml sebagai gantinya ruby ​​untuk melakukan perubahan skema. Meskipun saya tidak suka xml untuk bahasa khusus domain, keuntungan yang sangat keren dari xml adalah bahwa liquibase tahu cara mengembalikan operasi tertentu seperti

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

Jadi, Anda tidak perlu menangani ini sendiri

Pernyataan sql murni atau impor data juga didukung.

Kebanyakan mesin database harus mendukung dumping database Anda ke dalam sebuah file. Saya tahu MySQL melakukannya. Ini hanya akan menjadi file teks, jadi Anda bisa mengirimkannya ke Subversion, atau apapun yang Anda gunakan. Ini akan mudah untuk menjalankan diff pada file juga.

Jika Anda menggunakan SQL Server, akan sulit untuk mengalahkan Data Dude (alias Edisi Database Visual Studio). Setelah Anda memahaminya, melakukan perbandingan skema antara versi database yang dikontrol sumber dan versi dalam produksi sangatlah mudah. Dan dengan satu klik Anda dapat menghasilkan DDL diff Anda.

Ada video instruksional di MSDN yang sangat membantu.

Saya tahu tentang DBMS_METADATA dan Toad, tetapi jika seseorang dapat menemukan Data Dude untuk Oracle maka hidup akan sangat menyenangkan.

Minta pernyataan awal buat tabel di pengontrol versi, lalu tambahkan pernyataan alter tabel, tetapi jangan pernah mengedit file, cukup ubah file yang dinamai secara ideal secara berurutan, atau bahkan sebagai "set perubahan", sehingga Anda dapat menemukan semua perubahan untuk penerapan tertentu.

Bagian tersulit yang dapat saya lihat, adalah melacak dependensi, misalnya, untuk tabel penerapan tertentu B mungkin perlu diperbarui sebelum tabel A.

Untuk Oracle, saya menggunakan Toad , yang dapat membuang skema ke sejumlah file diskrit (misalnya, satu file per tabel). Saya memiliki beberapa skrip yang mengelola koleksi ini di Perforce, tetapi menurut saya itu semestinya dapat dengan mudah dilakukan di hampir semua sistem kontrol revisi.

Lihatlah paket oracle DBMS_METADATA.

Secara khusus, metode berikut sangat berguna:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

Setelah Anda terbiasa dengan cara kerjanya (cukup jelas), Anda dapat menulis skrip sederhana untuk membuang hasil metode tersebut ke dalam file teks yang dapat diletakkan di bawah kendali sumber. Semoga berhasil!

Tidak yakin apakah ada sesuatu yang sesederhana ini untuk MSSQL.

Saya menulis skrip rilis db saya secara paralel dengan pengkodean, dan menyimpan skrip rilis di bagian khusus proyek di SS. Jika saya membuat perubahan pada kode yang membutuhkan perubahan db, maka saya memperbarui skrip rilis pada saat yang bersamaan. Sebelum rilis, saya menjalankan skrip rilis pada dev db bersih (struktur disalin bijaksana dari produksi) dan melakukan pengujian akhir saya di atasnya.

Saya telah melakukan ini selama bertahun-tahun - mengelola (atau mencoba mengelola) versi skema. Pendekatan terbaik bergantung pada alat yang Anda miliki. Jika Anda bisa mendapatkan alat Quest Software "Manajer Skema", Anda akan dalam kondisi yang baik. Oracle memiliki alatnya sendiri yang lebih rendah yang juga disebut "Schema Manager" (membingungkan banyak?) Yang tidak saya rekomendasikan.

Tanpa alat otomatis (lihat komentar lain di sini tentang Data Dude) maka Anda akan menggunakan skrip dan file DDL secara langsung. Pilih pendekatan, dokumentasikan, dan ikuti dengan cermat. Saya suka memiliki kemampuan untuk membuat ulang database pada saat tertentu, jadi saya lebih suka memiliki ekspor DDL penuh dari seluruh database (jika saya DBA), atau skema pengembang (jika saya menggunakan produk -development mode).

Pengembang PLSQL, alat dari All Arround Automations, memiliki plugin untuk repositori yang berfungsi OK (tapi tidak hebat) dengan Visual Source Safe.

Dari web:

Plug-In Kontrol Versi menyediakan integrasi yang erat antara PL / SQL Developer IDE >> dan Sistem Kontrol Versi apa pun yang mendukung Spesifikasi Antarmuka Microsoft SCC. >> Ini termasuk Sistem Kontrol Versi yang paling populer seperti Microsoft Visual SourceSafe, >> Merant PVCS dan MKS Source Integrity.

http://www.allroundautomations.com/plsvcs.html

ER Studio memungkinkan Anda untuk membalik skema database Anda menjadi alat dan Anda kemudian dapat membandingkannya dengan database langsung.

Contoh: Balik skema pengembangan Anda menjadi ER Studio - bandingkan dengan produksi dan semua perbedaannya akan tercantum. Itu dapat membuat skrip perubahan atau hanya mendorongnya secara otomatis.

Setelah Anda memiliki skema di ER Studio, Anda dapat menyimpan skrip pembuatan atau menyimpannya sebagai biner berpemilik dan menyimpannya di kontrol versi. Jika Anda ingin kembali ke versi skema sebelumnya, cukup periksa dan dorong ke platform db Anda.

Ada "kerangka migrasi database" PHP5 yang disebut Ruckusing. Saya belum pernah menggunakannya, tetapi contoh menunjukkan idenya, jika Anda menggunakan bahasa untuk membuat database saat dan saat diperlukan, Anda hanya perlu melacak file sumber.

Anda dapat menggunakan Alat Data Microsoft SQL Server di studio visual untuk membuat skrip untuk objek database sebagai bagian dari Proyek SQL Server. Anda kemudian dapat menambahkan skrip ke kontrol sumber menggunakan integrasi kontrol sumber yang dibangun ke dalam studio visual. Selain itu, Proyek SQL Server memungkinkan Anda memverifikasi objek database menggunakan kompiler dan membuat skrip penerapan untuk memperbarui database yang ada atau membuat yang baru.

Kami telah menggunakan MS Team System Database Edition dengan kesuksesan yang cukup baik. Ini terintegrasi dengan kontrol versi TFS dan Visual Studio lebih atau kurang mulus dan memungkinkan kita untuk mengelola procs yang disimpan, tampilan, dll, dengan mudah. Resolusi konflik bisa menyebalkan, tetapi riwayat versi selesai setelah selesai. Setelah itu, migrasi ke QA dan produksi sangat sederhana.

Cukup adil untuk mengatakan bahwa ini adalah produk versi 1.0, dan bukan tanpa beberapa masalah.

Perbandingan Skema untuk Oracle adalah alat yang dirancang khusus untuk memigrasi perubahan dari database Oracle ke database lain. Silakan kunjungi URL di bawah ini untuk tautan unduhan, di mana Anda akan dapat menggunakan perangkat lunak untuk uji coba yang berfungsi penuh.

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

Dengan tidak adanya VCS untuk perubahan tabel, saya telah memasukkannya ke dalam wiki. Setidaknya saya bisa melihat kapan dan mengapa itu diubah. Ini jauh dari sempurna karena tidak semua orang melakukannya dan kami memiliki beberapa versi produk yang digunakan, tetapi lebih baik daripada tidak sama sekali.

Saya akan merekomendasikan salah satu dari dua pendekatan. Pertama, berinvestasi di PowerDesigner dari Sybase. Edisi Perusahaan. Ini memungkinkan Anda untuk merancang model data Fisik, dan banyak lagi lainnya. Tapi itu datang dengan repositori yang memungkinkan Anda untuk memeriksa model Anda. Setiap check in baru bisa menjadi versi baru, itu bisa membandingkan versi apa pun dengan versi lain dan bahkan dengan apa yang ada di database Anda pada saat itu. Ini kemudian akan menampilkan daftar setiap perbedaan dan menanyakan mana yang harus dimigrasi… dan kemudian membangun skrip untuk melakukannya. Itu tidak murah tapi itu murah dengan harga dua kali lipat dan ROI-nya sekitar 6 bulan.

Ide lainnya adalah mengaktifkan audit DDL (bekerja di Oracle). Ini akan membuat tabel dengan setiap perubahan yang Anda buat. Jika Anda menanyakan perubahan dari stempel waktu terakhir kali Anda memindahkan perubahan database Anda ke prod sekarang, Anda akan memiliki daftar urutan semua yang telah Anda lakukan. Beberapa klausa di mana untuk menghilangkan perubahan jumlah-nol seperti create table foo; diikuti oleh drop table foo; dan Anda dengan MUDAH dapat membuat skrip mod. Mengapa menyimpan perubahan di wiki, itu menggandakan pekerjaan. Biarkan database melacaknya untuk Anda.

Rekomendasi dua buku: "Refactoring Database" oleh Ambler dan Sadalage dan "Agile Database Techniques" oleh Ambler.

Seseorang menyebutkan Migrasi Rails. Saya pikir mereka bekerja dengan baik, bahkan di luar aplikasi Rails. Saya menggunakannya pada aplikasi ASP dengan SQL Server yang kami sedang dalam proses pindah ke Rails. Anda memeriksa sendiri skrip migrasi ke VCS. Berikut adalah posting oleh Dave Thomas Pragmatis tentang masalah ini.