Tujuan artikel ini adalah menggunakan contoh perpustakaan penjaga skema tunjukkan alat yang secara signifikan dapat menyederhanakan proses pengembangan database dalam proyek PHP menggunakan DBMS PostgreSQL.

Informasi dari artikel ini, pertama-tama, akan berguna bagi pengembang yang ingin memanfaatkan kemampuan PostgreSQL secara maksimal, namun dihadapkan pada masalah dalam mempertahankan logika bisnis yang ditempatkan di database.

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

Pertanyaan-pertanyaan berikut akan dipertimbangkan:

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

   Penjaga Skema dirancang untuk bekerja dengan prosedur tersimpan yang ditulis dalam bahasa tersebut PL/pgSQL. Pengujian dengan bahasa lain belum dilakukan, sehingga penggunaannya mungkin tidak seefektif atau mungkin tidak dapat dilakukan.

Cara menyimpan dump struktur database di VCS

perpustakaan penjaga skema menyediakan suatu fungsi saveDump, yang menyimpan struktur semua objek dari database sebagai file teks terpisah. Outputnya adalah direktori yang berisi struktur database, dibagi menjadi beberapa file yang dikelompokkan sehingga dapat dengan mudah ditambahkan ke VCS.

Mari kita lihat mengonversi objek dari database menjadi file menggunakan beberapa contoh:

Jenis objek
Skema itu
Nama
Jalur relatif ke file

tabel
publik
akun
./public/tables/accounts.txt

Prosedur tersimpan
publik
autentikasi (hash bigint)
./public/functions/auth(int8).sql

Pendahuluan
pemesanan
tarif
./booking/views/tariffs.txt

Isi 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, jalur ke file menyimpan informasi tentang jenis, skema, dan nama objek. Pendekatan ini mempermudah navigasi melalui dump dan tinjauan kode perubahan dalam database.

perpanjangan .sql untuk file dengan kode sumber prosedur tersimpan, ini dipilih sehingga IDE secara otomatis menyediakan alat untuk berinteraksi dengan database ketika file dibuka.

Cara melacak perubahan struktur database setelah menyimpan dump

Dengan menyimpan dump dari struktur database saat ini di VCS, kita mendapat kesempatan untuk memeriksa apakah ada perubahan pada struktur database setelah dump dibuat. Di perpustakaan penjaga skema untuk mendeteksi perubahan struktur database, disediakan fungsi verifyDump, yang mengembalikan informasi tentang perbedaan tanpa efek samping.

Cara alternatif untuk memeriksanya adalah dengan memanggil kembali fungsi tersebut saveDump, tentukan direktori yang sama, dan periksa perubahan di VCS. Karena semua objek dari database disimpan dalam file terpisah, VCS hanya akan menampilkan objek yang diubah.
Kerugian utama dari metode ini adalah kebutuhan untuk menimpa file untuk melihat perubahannya.

Cara mentransfer perubahan struktur database ke lingkungan lain tanpa konflik dan file migrasi raksasa

Berkat fungsinya deployDump Kode sumber prosedur tersimpan dapat diedit dengan cara yang persis sama seperti kode sumber aplikasi biasa. Anda dapat menambah/menghapus baris baru dalam kode prosedur tersimpan dan segera mendorong perubahan ke kontrol versi, atau membuat/menghapus prosedur tersimpan dengan membuat/menghapus file terkait di direktori dump.

Misalnya, untuk membuat prosedur tersimpan baru dalam suatu skema public cukup buat file baru dengan ekstensi .sql di direktori public/functions, tempatkan kode sumber dari prosedur tersimpan di dalamnya, termasuk bloknya CREATE OR REPLACE FUNCTION, lalu panggil fungsinya deployDump. Memodifikasi dan menghapus prosedur tersimpan terjadi dengan cara yang sama. Dengan demikian, kode tersebut masuk ke VCS dan database secara bersamaan.

Jika kesalahan muncul dalam kode sumber dari setiap prosedur tersimpan, atau perbedaan antara nama file dan prosedur tersimpan, maka deployDump akan gagal, menampilkan teks kesalahan. Ketidakcocokan prosedur tersimpan antara dump dan database saat ini tidak mungkin terjadi saat menggunakan deployDump.

Saat membuat prosedur tersimpan baru, tidak perlu memasukkan nama file yang benar secara manual. File tersebut cukup memiliki ekstensi .sql. Setelah panggilan deployDump teks kesalahan akan berisi nama yang benar, yang dapat digunakan untuk mengganti nama file.

deployDump memungkinkan Anda mengubah parameter suatu fungsi atau tipe kembalian tanpa tindakan tambahan, sedangkan dengan pendekatan klasik Anda harus melakukannya
jalankan terlebih dahulu DROP FUNCTION, dan hanya kemudian CREATE OR REPLACE FUNCTION.

Sayangnya, ada beberapa situasi di mana deployDump tidak dapat 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 Anda bertanggung jawab untuk memigrasikan perubahan ke prosedur tersimpan penjaga skema, maka file migrasi harus digunakan untuk mentransfer perubahan lain dalam struktur. Misalnya, perpustakaan yang bagus untuk bekerja dengan migrasi adalah doktrin/migrasi.

Migrasi harus diterapkan sebelum peluncuran deployDump. Hal ini memungkinkan Anda untuk membuat semua perubahan pada struktur dan menyelesaikan situasi masalah sehingga perubahan dalam prosedur tersimpan selanjutnya ditransfer tanpa masalah.

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

Bagaimana mengatur proses kerja paralel pada suatu proyek oleh beberapa pengembang

Penting untuk membuat skrip untuk inisialisasi database lengkap, yang akan diluncurkan oleh pengembang di mesin kerjanya, menjadikan struktur database lokal sesuai dengan dump yang disimpan di VCS. Cara termudah adalah dengan membagi inisialisasi database lokal menjadi 3 langkah:

1. Impor file dengan struktur dasar yang akan dipanggil mis. base.sql
2. Menerapkan Migrasi
3. Tantangan deployDump

base.sql adalah titik awal di mana migrasi diterapkan dan dijalankan deployDumpitu adalah base.sql + миграции + deployDump = актуальная структура БД. Anda dapat membuat file seperti itu menggunakan utilitas pg_dump. Digunakan base.sql secara eksklusif saat menginisialisasi database dari awal.

Mari kita panggil skrip untuk inisialisasi database lengkap refresh.sh. Alur kerjanya mungkin terlihat seperti ini:

1. Pengembang meluncurkan di lingkungannya refresh.sh dan mendapatkan struktur database saat ini
2. Pengembang mulai mengerjakan tugas yang ada, memodifikasi database lokal untuk memenuhi kebutuhan fungsionalitas baru (ALTER TABLE ... ADD COLUMN dll)
3. Setelah menyelesaikan tugas, pengembang memanggil fungsi tersebut saveDumpuntuk melakukan perubahan yang dibuat pada database di VCS
4. Peluncuran kembali pengembang refresh.sh, lalu verifyDumpyang sekarang menampilkan daftar perubahan untuk disertakan dalam migrasi
5. Pengembang mentransfer semua perubahan struktur ke file migrasi, berjalan kembali refresh.sh и verifyDump, dan, jika migrasi dikompilasi dengan benar, verifyDump tidak akan menunjukkan perbedaan antara database lokal dan dump yang disimpan

Proses yang dijelaskan di atas kompatibel dengan prinsip gitflow. Setiap cabang di VCS akan berisi versi dumpnya sendiri, dan saat menggabungkan cabang, dump tersebut akan digabungkan. Dalam kebanyakan kasus, tidak ada tindakan tambahan yang perlu diambil setelah penggabungan, tetapi jika perubahan dilakukan di cabang yang berbeda, misalnya pada tabel yang sama, konflik mungkin timbul.

Mari kita perhatikan situasi konflik dengan menggunakan contoh: ada cabang mengembangkan, dari mana dua cabang bercabang: feature1 и feature2, yang tidak memiliki konflik dengan mengembangkan, tetapi memiliki konflik satu sama lain. Tugasnya adalah menggabungkan kedua cabang menjadi mengembangkan. Untuk kasus ini, disarankan untuk menggabungkan salah satu cabang terlebih dahulu mengembangkandan kemudian bergabung mengembangkan ke cabang yang tersisa, menyelesaikan konflik di cabang yang tersisa, dan kemudian menggabungkan cabang terakhir ke dalamnya mengembangkan. Selama fase resolusi konflik, Anda mungkin harus memperbaiki file migrasi di cabang terakhir agar cocok dengan dump akhir, yang mencakup hasil penggabungan.

Cara menyebarkan lebih banyak perubahan dalam struktur database dengan aman ke lingkungan produksi

Berkat adanya dump dari struktur database saat ini di VCS, database produksi dapat diperiksa untuk kesesuaian yang tepat dengan struktur yang diperlukan. Hal ini memastikan bahwa semua perubahan yang diinginkan pengembang berhasil ditransfer ke basis produksi.

Sebagai HAL-HAL di PostgreSQL adalah transaksional, disarankan untuk mematuhi urutan penerapan berikut, sehingga, jika terjadi kesalahan yang tidak terduga, Anda dapat mengeksekusinya “tanpa rasa sakit” ROLLBACK:

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 dapat dengan mudah diintegrasikan ke dalam pendekatan penerapan aplikasi yang ada, termasuk zero-downtime.

Kesimpulan

Berkat metode yang dijelaskan di atas, dimungkinkan untuk memaksimalkan kinerja proyek “PHP + PostgreSQL”, sambil mengorbankan kenyamanan pengembangan yang relatif sedikit dibandingkan dengan menerapkan semua logika bisnis dalam kode aplikasi utama. Apalagi pengolahan data di PL/pgSQL sering kali terlihat lebih transparan dan membutuhkan lebih sedikit kode dibandingkan fungsi yang sama yang ditulis dalam PHP.

Sumber: www.habr.com