ProHoster > Blog > Pentadbiran > Logik perniagaan dalam pangkalan data menggunakan SchemaKeeper

Logik perniagaan dalam pangkalan data menggunakan SchemaKeeper

Tujuan artikel ini adalah untuk menggunakan contoh perpustakaan penjaga skema tunjukkan alatan yang boleh memudahkan proses membangunkan pangkalan data dalam projek PHP dengan ketara menggunakan DBMS PostgreSQL.

Maklumat daripada artikel ini, pertama sekali, berguna kepada pembangun yang ingin memanfaatkan sepenuhnya keupayaan PostgreSQL, tetapi berhadapan dengan masalah mengekalkan logik perniagaan yang diletakkan dalam pangkalan data.

Artikel ini tidak akan menerangkan kelebihan atau kekurangan menyimpan logik perniagaan dalam pangkalan data. Diandaikan bahawa pilihan telah pun dibuat oleh pembaca.

Soalan berikut akan dipertimbangkan:

  1. Dalam bentuk apakah pelupusan struktur pangkalan data harus disimpan dalam sistem kawalan versi (selepas ini dirujuk sebagai VCS)
  2. Bagaimana untuk mengesan perubahan dalam struktur pangkalan data selepas menyimpan dump
  3. Bagaimana untuk memindahkan perubahan dalam struktur pangkalan data ke persekitaran lain tanpa konflik dan fail migrasi gergasi
  4. Bagaimana untuk mengatur proses kerja selari pada projek oleh beberapa pemaju
  5. Cara selamat menggunakan lebih banyak perubahan dalam struktur pangkalan data kepada persekitaran pengeluaran

    SchemaKeeper direka untuk bekerja dengan prosedur tersimpan yang ditulis dalam bahasa PL/pgSQL. Ujian dengan bahasa lain belum dijalankan, jadi penggunaan mungkin tidak berkesan atau mungkin tidak mungkin.

Bagaimana untuk menyimpan pembuangan struktur pangkalan data dalam VCS

Perpustakaan penjaga skema menyediakan fungsi saveDump, yang menyimpan struktur semua objek daripada pangkalan data sebagai fail teks yang berasingan. Output ialah direktori yang mengandungi struktur pangkalan data, dibahagikan kepada fail berkumpulan yang boleh ditambah dengan mudah pada VCS.

Mari kita lihat menukar objek daripada pangkalan data kepada fail menggunakan beberapa contoh:

Jenis objek
Skim ini
nama
Laluan relatif kepada fail

Rajah
awam
akaun
./public/tables/accounts.txt

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

Pengenalan
tempahan
tarif
./booking/views/tariffs.txt

Kandungan fail adalah perwakilan teks struktur objek pangkalan data tertentu. Sebagai contoh, untuk prosedur tersimpan, kandungan fail akan menjadi definisi penuh prosedur tersimpan, bermula dengan blok CREATE OR REPLACE FUNCTION.

Seperti yang dapat dilihat daripada jadual di atas, laluan ke fail menyimpan maklumat tentang jenis, skema dan nama objek. Pendekatan ini menjadikannya lebih mudah untuk menavigasi melalui pembuangan dan semakan kod perubahan dalam pangkalan data.

lanjutan .sql untuk fail dengan kod sumber prosedur tersimpan, ini dipilih supaya IDE secara automatik menyediakan alat untuk berinteraksi dengan pangkalan data apabila fail dibuka.

Bagaimana untuk mengesan perubahan dalam struktur pangkalan data selepas menyimpan dump

Dengan menyimpan longgokan struktur pangkalan data semasa dalam VCS, kami mendapat peluang untuk menyemak sama ada perubahan telah dibuat pada struktur pangkalan data selepas longgokan dibuat. Di perpustakaan penjaga skema untuk mengesan perubahan dalam struktur pangkalan data, fungsi disediakan verifyDump, yang mengembalikan maklumat tentang perbezaan tanpa kesan sampingan.

Cara alternatif untuk menyemak adalah dengan memanggil fungsi itu semula saveDump, menyatakan direktori yang sama, dan semak dalam VCS untuk perubahan. Memandangkan semua objek daripada pangkalan data disimpan dalam fail berasingan, VCS hanya akan menunjukkan objek yang diubah.
Kelemahan utama kaedah ini ialah keperluan untuk menulis ganti fail untuk melihat perubahan.

Bagaimana untuk memindahkan perubahan dalam struktur pangkalan data ke persekitaran lain tanpa konflik dan fail migrasi gergasi

Terima kasih kepada fungsi deployDump Kod sumber prosedur tersimpan boleh diedit dengan cara yang sama seperti kod sumber aplikasi biasa. Anda boleh menambah/memadam baris baharu dalam kod prosedur tersimpan dan segera menolak perubahan kepada kawalan versi, atau mencipta/memadam prosedur tersimpan dengan mencipta/memadam fail yang sepadan dalam direktori dump.

Contohnya, untuk mencipta prosedur tersimpan baharu dalam skema public hanya buat fail baharu dengan sambungan .sql dalam direktori public/functions, letakkan kod sumber prosedur tersimpan di dalamnya, termasuk blok CREATE OR REPLACE FUNCTION, kemudian panggil fungsi tersebut deployDump. Mengubah suai dan memadamkan prosedur tersimpan berlaku dengan cara yang sama. Oleh itu, kod tersebut masuk ke dalam kedua-dua VCS dan pangkalan data pada masa yang sama.

Jika ralat muncul dalam kod sumber mana-mana prosedur yang disimpan, atau percanggahan antara nama fail dan prosedur yang disimpan, maka deployDump akan gagal, memaparkan teks ralat. Ketidakpadanan prosedur tersimpan antara dump dan pangkalan data semasa adalah mustahil apabila digunakan deployDump.

Apabila mencipta prosedur tersimpan baharu, tidak perlu memasukkan nama fail yang betul secara manual. Ia cukup untuk fail mempunyai sambungan .sql. Selepas panggilan deployDump teks ralat akan mengandungi nama yang betul, yang boleh digunakan untuk menamakan semula fail.

deployDump membolehkan anda menukar parameter fungsi atau jenis pengembalian tanpa tindakan tambahan, manakala dengan pendekatan klasik anda perlu
laksanakan dahulu DROP FUNCTION, dan hanya kemudian CREATE OR REPLACE FUNCTION.

Malangnya, terdapat beberapa situasi di mana deployDump tidak dapat menggunakan perubahan secara automatik. Contohnya, jika fungsi pencetus yang digunakan oleh sekurang-kurangnya satu pencetus dialih keluar. Situasi sedemikian diselesaikan secara manual menggunakan fail migrasi.

Jika anda bertanggungjawab untuk memindahkan perubahan kepada prosedur tersimpan penjaga skema, maka fail migrasi mesti digunakan untuk memindahkan perubahan lain dalam struktur. Sebagai contoh, perpustakaan yang baik untuk bekerja dengan migrasi ialah doktrin/hijrah.

Migrasi mesti digunakan sebelum pelancaran deployDump. Ini membolehkan anda membuat semua perubahan pada struktur dan menyelesaikan situasi bermasalah supaya perubahan dalam prosedur tersimpan kemudiannya dipindahkan tanpa masalah.

Bekerja dengan migrasi akan diterangkan dengan lebih terperinci dalam bahagian berikut.

Bagaimana untuk mengatur proses kerja selari pada projek oleh beberapa pemaju

Ia adalah perlu untuk mencipta skrip untuk permulaan lengkap pangkalan data, yang akan dilancarkan oleh pembangun pada mesin kerjanya, membawa struktur pangkalan data tempatan mengikut dump yang disimpan dalam VCS. Cara paling mudah ialah membahagikan permulaan pangkalan data tempatan kepada 3 langkah:

  1. Import fail dengan struktur asas yang akan dipanggil cth. base.sql
  2. Memohon Migrasi
  3. Panggil deployDump

base.sql ialah titik permulaan di mana migrasi digunakan dan dilaksanakan deployDumpIaitu, base.sql + ΠΌΠΈΠ³Ρ€Π°Ρ†ΠΈΠΈ + deployDump = Π°ΠΊΡ‚ΡƒΠ°Π»ΡŒΠ½Π°Ρ структура Π‘Π”. Anda boleh membuat fail sedemikian menggunakan utiliti pg_dump. terpakai base.sql secara eksklusif apabila memulakan pangkalan data dari awal.

Mari kita panggil skrip untuk permulaan pangkalan data lengkap refresh.sh. Aliran kerja mungkin kelihatan seperti ini:

  1. Pemaju melancarkan dalam persekitarannya refresh.sh dan mendapat struktur pangkalan data semasa
  2. Pembangun mula bekerja pada tugas di tangan, mengubah suai pangkalan data tempatan untuk memenuhi keperluan fungsi baharu (ALTER TABLE ... ADD COLUMN dan lain-lain)
  3. Selepas menyelesaikan tugas, pembangun memanggil fungsi tersebut saveDumpuntuk melakukan perubahan yang dibuat pada pangkalan data dalam VCS
  4. Pelancaran semula pemaju refresh.shkemudian verifyDumpyang kini menunjukkan senarai perubahan untuk disertakan dalam migrasi
  5. Pembangun memindahkan semua perubahan struktur ke fail migrasi, berjalan semula refresh.sh ΠΈ verifyDump, dan, jika migrasi disusun dengan betul, verifyDump tidak akan menunjukkan perbezaan antara pangkalan data tempatan dan dump yang disimpan

Proses yang diterangkan di atas adalah serasi dengan prinsip gitflow. Setiap cawangan dalam VCS akan mengandungi versi pembuangannya sendiri dan apabila menggabungkan cawangan, tempat pembuangan akan digabungkan. Dalam kebanyakan kes, tiada tindakan tambahan perlu diambil selepas penggabungan, tetapi jika perubahan dibuat di cawangan yang berbeza, contohnya, ke jadual yang sama, konflik mungkin timbul.

Mari kita pertimbangkan situasi konflik menggunakan contoh: ada cabang membangunkan, dari mana dua cabang bercabang: ciri1 ΠΈ ciri2, yang tidak mempunyai konflik dengan membangunkan, tetapi mempunyai konflik antara satu sama lain. Tugasnya adalah untuk menggabungkan kedua-dua cawangan menjadi membangunkan. Untuk kes ini, disyorkan untuk menggabungkan salah satu cawangan terlebih dahulu membangunkandan kemudian bergabung membangunkan ke cawangan yang tinggal, menyelesaikan konflik dalam cawangan yang tinggal, dan kemudian menggabungkan cawangan terakhir ke dalam membangunkan. Semasa fasa penyelesaian konflik, anda mungkin perlu membetulkan fail migrasi di cawangan terakhir supaya ia sepadan dengan pembuangan akhir, yang termasuk hasil gabungan.

Cara selamat menggunakan lebih banyak perubahan dalam struktur pangkalan data kepada persekitaran pengeluaran

Terima kasih kepada kehadiran pembuangan struktur pangkalan data semasa dalam VCS, adalah mungkin untuk menyemak pangkalan data pengeluaran untuk pematuhan tepat dengan struktur yang diperlukan. Ini memastikan bahawa semua perubahan yang dimaksudkan oleh pembangun berjaya dipindahkan ke pangkalan pengeluaran.

Sebagai DDL dalam PostgreSQL ialah transaksional, adalah disyorkan untuk mematuhi perintah penempatan berikut, supaya, sekiranya berlaku ralat yang tidak dijangka, anda boleh "tanpa rasa sakit" melaksanakan ROLLBACK:

  1. Mulakan transaksi
  2. Lakukan semua migrasi dalam transaksi
  3. Dalam transaksi yang sama, laksanakan deployDump
  4. Tanpa melengkapkan transaksi, laksanakan verifyDump. Jika tiada ralat, jalankan COMMIT. Jika terdapat ralat, jalankan ROLLBACK

Langkah-langkah ini boleh disepadukan dengan mudah ke dalam pendekatan sedia ada untuk penggunaan aplikasi, termasuk masa henti sifar.

Kesimpulan

Terima kasih kepada kaedah yang diterangkan di atas, adalah mungkin untuk memerah prestasi maksimum daripada projek "PHP + PostgreSQL", sambil mengorbankan kemudahan pembangunan yang agak sedikit berbanding dengan melaksanakan semua logik perniagaan dalam kod aplikasi utama. Selain itu, pemprosesan data dalam PL/pgSQL selalunya kelihatan lebih telus dan memerlukan kurang kod daripada fungsi yang sama yang ditulis dalam PHP.

Sumber: www.habr.com

Tambah komen