Begitu banyak orang mencoba melakukan hal semacam ini (skema diff). Pendapat saya adalah
- Kode sumber masuk ke alat kontrol versi (Subversion, CSV, GIT, Perforce ...). Perlakukan seolah-olah itu kode Java atau C, itu benar-benar tidak berbeda. Anda harus memiliki proses penginstalan yang memeriksanya dan menerapkannya ke database.
- DDL ADALAH KODE SUMBER. Itu juga masuk ke alat kontrol versi.
- Data adalah area abu-abu - tabel pencarian mungkin harus ada di alat kontrol versi. Data yang dihasilkan aplikasi tentu tidak.
Cara saya melakukan banyak hal akhir-akhir ini adalah membuat skrip migrasi yang mirip dengan migrasi Ruby on Rails. Masukkan DDL Anda ke dalam skrip dan jalankan untuk memindahkan database antar versi. Mengelompokkan perubahan untuk rilis ke dalam satu file atau kumpulan file. Kemudian Anda memiliki skrip yang memindahkan aplikasi Anda dari versi x ke versi y.
Satu hal yang tidak pernah saya lakukan lagi (dan saya biasa melakukannya sampai saya belajar lebih baik) adalah menggunakan alat GUI apa pun untuk membuat objek basis data di lingkungan pengembangan saya. Tulis skrip DDL dari hari 1 - Anda akan tetap membutuhkannya untuk mempromosikan kode untuk pengujian, produksi, dll. Saya telah melihat begitu banyak orang yang menggunakan GUI untuk membuat semua objek dan datanglah waktu rilis, ada scrabble untuk mencoba menghasilkan skrip untuk membuat/memigrasikan skema dengan benar yang sering kali tidak diuji dan gagal!
Setiap orang akan memiliki preferensi mereka sendiri tentang bagaimana melakukan ini, tetapi saya telah melihat banyak dari itu dilakukan dengan buruk selama bertahun-tahun yang membentuk pendapat saya di atas.
