Tujuan artikel ini adalah untuk menggunakan perpustakaan schema-keeper sebagai contoh untuk menunjukkan alat untuk menyederhanakan pengembangan database dalam proyek PHP menggunakan DBMS PostgreSQL.

Masalah-masalah berikut akan dibahas:

1. Dalam bentuk apa untuk menyimpan dump struktur database dalam sistem kontrol versi (selanjutnya - VCS)
2. Cara melacak perubahan dalam struktur database setelah menyimpan dump
3. Cara mentransfer perubahan dalam struktur basis data ke lingkungan lain tanpa konflik dan file migrasi raksasa
4. Bagaimana membangun proses kerja paralel pada suatu proyek oleh beberapa pengembang
5. Cara menerapkan lebih banyak perubahan pada struktur basis data ke lingkungan produksi dengan aman

Informasi dari artikel ini terutama akan bermanfaat bagi pengembang yang ingin memanfaatkan kemampuan PostgreSQL sebaik-baiknya, tetapi menghadapi masalah dalam mempertahankan logika bisnis dalam database.

Artikel ini tidak akan menjelaskan kelebihan atau kekurangan dari menyimpan logika bisnis dalam database. Diasumsikan bahwa pilihan sudah dibuat oleh pembaca.

SchemaKeeper dirancang untuk bekerja dengan prosedur tersimpan yang ditulis dalam PL / pgSQL . Pengujian dengan bahasa lain tidak dilakukan, jadi penggunaannya mungkin tidak seefektif atau tidak mungkin.

Dalam bentuk apa untuk menyimpan dump struktur database di VCS

Perpustakaan schema-keeper menyediakan fungsi saveDump , yang menyimpan struktur objek dari database sebagai file teks terpisah. Output menciptakan direktori yang berisi struktur database, dibagi menjadi file yang dikelompokkan yang mudah ditambahkan ke VCS.

Pertimbangkan untuk mengonversi objek dari database ke file dengan beberapa contoh:

Konten file adalah representasi tekstual dari struktur objek database tertentu. Misalnya, untuk prosedur tersimpan, isi file akan menjadi definisi lengkap dari prosedur tersimpan, dimulai dengan blok CREATE OR REPLACE FUNCTION .

Seperti dapat dilihat dari tabel di atas, path file menyimpan informasi tentang jenis, skema, dan nama objek. Pendekatan ini membuatnya mudah dinavigasi melalui dump dan perubahan tinjauan kode ke database.

.sql untuk file dengan kode sumber untuk prosedur tersimpan dipilih sehingga IDE secara otomatis menyediakan alat untuk berinteraksi dengan database saat membuka file.

Cara melacak perubahan dalam struktur database setelah menyimpan dump

Setelah menyimpan dump dari struktur database saat ini di VCS, kami mendapat kesempatan untuk memeriksa apakah perubahan dibuat pada struktur database setelah membuat dump. Pustaka skema-penjaga menyediakan fungsi memverifikasiDump untuk mendeteksi perubahan struktur database, yang mengembalikan informasi tentang perbedaan tanpa efek samping.

Cara alternatif untuk memeriksa adalah memanggil fungsi saveDump , menentukan direktori yang sama, dan memeriksa perubahan VCS. Karena objek dari database disimpan dalam file terpisah, VCS hanya akan menampilkan objek yang diubah. Kerugian utama dari metode ini adalah perlunya menimpa file untuk melihat perubahannya.

Cara mentransfer perubahan dalam struktur basis data ke lingkungan lain tanpa konflik dan file migrasi raksasa

Berkat fungsi deployDump, kode sumber dari prosedur yang tersimpan diedit sama seperti kode sumber aplikasi lainnya. Modifikasi prosedur tersimpan terjadi dengan membuat perubahan pada file yang sesuai, yang secara otomatis tercermin dalam sistem kontrol versi.

Misalnya, untuk membuat prosedur tersimpan baru dalam skema public , cukup membuat file baru dengan ekstensi .sql di direktori public/functions , tempatkan kode sumber prosedur tersimpan di dalamnya, termasuk blok CREATE OR REPLACE FUNCTION , lalu panggil fungsi deployDump . Demikian pula, prosedur tersimpan dimodifikasi dan dihapus. Dengan demikian, kode secara bersamaan memasuki VCS dan basis data.

Jika kesalahan muncul dalam kode sumber dari prosedur tersimpan, maka deployDump akan gagal, mengeluarkan pengecualian. Ketidakcocokan prosedur tersimpan antara dump dan database saat ini tidak mungkin menggunakan deployDump .

Saat membuat prosedur tersimpan baru, tidak perlu memasukkan nama file yang benar secara manual. Sudah cukup bahwa file tersebut memiliki ekstensi .sql . Nama yang benar dapat diperoleh dari nilai deployDump fungsi deployDump , dan digunakan untuk mengganti nama file.

deployDump mengubah parameter fungsi atau tipe pengembalian tanpa tindakan tambahan, sedangkan dalam pendekatan klasik akan diperlukan untuk melakukan DROP FUNCTION , dan hanya kemudian CREATE OR REPLACE FUNCTION .

Sayangnya, dalam beberapa situasi, deployDump gagal menerapkan perubahan secara otomatis. Misalnya, jika fungsi pemicu yang digunakan oleh setidaknya satu pemicu dihapus. Situasi seperti ini diselesaikan secara manual menggunakan file migrasi.

Jika penjaga skema bertanggung jawab untuk mentransfer perubahan dalam prosedur tersimpan, maka file migrasi digunakan untuk mentransfer perubahan lain dalam struktur. Sebagai contoh, perpustakaan doktrin / migrasi cocok.

Migrasi harus diterapkan sebelum menjalankan deployDump untuk membuat perubahan pada struktur dan menyelesaikan kemungkinan situasi masalah.

Bekerja dengan migrasi akan dijelaskan secara lebih rinci di bagian berikut.

Cara menetapkan proses kerja paralel pada suatu proyek oleh beberapa pengembang

Mari kita buat skrip untuk inisialisasi basis data lengkap, yang dijalankan pengembang pada mesin lokal untuk membawa struktur basis data lokal sejalan dengan dump yang disimpan di VCS. Kami membagi inisialisasi database lokal menjadi 3 langkah:

1. Impor file dengan struktur dasar, yang akan dipanggil, misalnya, base.sql
2. Aplikasi migrasi
3. Panggilan deployDump

base.sql adalah titik awal di mana migrasi diterapkan dan deployDump , yaitu, base.sql + + deployDump = . Digunakan oleh base.sql secara eksklusif saat menginisialisasi database dari awal. File seperti itu dihasilkan menggunakan pg_dump .

Kami memanggil skrip untuk inisialisasi inisialisasi basis data lengkap. Alur kerja pengembang adalah sebagai berikut:

1. Menjalankan refresh.sh di lingkungan Anda untuk mendapatkan struktur basis data saat ini
2. Mulai bekerja pada tugas, memodifikasi database lokal untuk kebutuhan fungsionalitas baru ( ALTER TABLE ... ADD COLUMN , dll.)
3. Setelah menyelesaikan tugas, panggil fungsi saveDump untuk melakukan perubahan yang dilakukan pada database di VCS
4. refresh.sh kemudian verifyDump untuk menampilkan daftar perubahan untuk dimasukkan dalam migrasi
5. Mentransfer perubahan struktur ke file migrasi, menjalankan refresh.sh dan verifyDump , dan jika migrasi verifyDump dengan benar, verifyDump

Proses yang dijelaskan di atas kompatibel dengan prinsip-prinsip gitflow . Setiap cabang di VCS berisi versinya sendiri dari dump, dan ketika cabang bergabung, dumps bergabung. Merger dilakukan tanpa tindakan tambahan, tetapi jika perubahan dilakukan di cabang, misalnya, ke tabel yang sama, konflik mungkin terjadi.

Pertimbangkan situasi konflik menggunakan contoh cabang berkembang , dari mana cabang1 dan cabang2 bercabang , yang tidak bertentangan dengan pengembangan , tetapi konflik satu sama lain. Tugasnya adalah menggabungkan branch1 dan branch2 menjadi berkembang. Untuk kasus seperti itu, Anda disarankan untuk pertama-tama menggabungkan branch1 menjadi development , dan kemudian menggabungkan development menjadi branch2 , menyelesaikan konflik di branch2 , dan kemudian menggabungkan branch2 menjadi development . Pada tahap resolusi konflik, Anda mungkin perlu memperbaiki file migrasi di branch2 sehingga cocok dengan dump akhir, yang mencakup hasil merger.

Bagaimana cara menerapkan lebih banyak perubahan pada struktur basis data ke lingkungan produksi secara aman

Kehadiran dalam dump VCS dari struktur database saat ini memungkinkan Anda untuk memeriksa basis produksi untuk kepatuhan yang tepat dengan struktur yang diperlukan. Ini memastikan bahwa semua perubahan yang dimaksudkan pengembang dipindahkan ke basis produksi.

Karena DDL di PostgreSQL bersifat transaksional , disarankan agar Anda mengikuti urutan penerapan sehingga, jika terjadi kesalahan yang tidak terduga, ROLLBACK "tidak menyakitkan":

1. Mulai transaksi
2. Lakukan semua migrasi dalam suatu transaksi
3. Dalam transaksi yang sama, jalankan deployDump
4. Tanpa menyelesaikan transaksi, jalankan verifyDump . Jika tidak ada kesalahan, jalankan COMMIT . Jika ada kesalahan, jalankan ROLLBACK

Langkah-langkah ini cukup mudah untuk diintegrasikan ke dalam pendekatan yang ada untuk menyebarkan aplikasi, termasuk zero-downtime.

Kesimpulan

Berkat metode yang dijelaskan di atas, Anda dapat memeras kinerja maksimum dari proyek "PHP + PostgreSQL", sambil mengorbankan sejumlah kecil kenyamanan pengembangan dibandingkan dengan penerapan semua logika bisnis dalam kode aplikasi utama. Selain itu, pemrosesan data dalam PL / pgSQL sering terlihat lebih transparan dan membutuhkan lebih sedikit kode daripada fungsi yang sama yang ditulis dalam PHP.