ຈຸດປະສົງຂອງບົດຄວາມນີ້ແມ່ນເພື່ອນໍາໃຊ້ຕົວຢ່າງຂອງຫ້ອງສະຫມຸດ schema-keeper ສະແດງໃຫ້ເຫັນເຄື່ອງມືທີ່ສາມາດເຮັດໃຫ້ຂະບວນການພັດທະນາຖານຂໍ້ມູນພາຍໃນໂຄງການ PHP ງ່າຍຂຶ້ນຫຼາຍໂດຍໃຊ້ PostgreSQL DBMS.

ຂໍ້ມູນຈາກບົດຄວາມນີ້, ກ່ອນອື່ນ ໝົດ, ເປັນປະໂຫຍດຕໍ່ນັກພັດທະນາທີ່ຕ້ອງການໃຊ້ຄວາມສາມາດຂອງ PostgreSQL, ແຕ່ປະເຊີນກັບບັນຫາການຮັກສາເຫດຜົນທາງທຸລະກິດທີ່ວາງໄວ້ໃນຖານຂໍ້ມູນ.

ບົດຄວາມນີ້ຈະບໍ່ອະທິບາຍຂໍ້ດີຫຼືຂໍ້ເສຍຂອງການເກັບຮັກສາເຫດຜົນທາງທຸລະກິດໃນຖານຂໍ້ມູນ. ມັນສົມມຸດວ່າທາງເລືອກໄດ້ຖືກເຮັດແລ້ວໂດຍຜູ້ອ່ານ.

ຄຳຖາມຕໍ່ໄປນີ້ຈະຖືກພິຈາລະນາ:

1. ການຖິ້ມໂຄງສ້າງຖານຂໍ້ມູນຄວນຖືກເກັບໄວ້ໃນຮູບແບບໃດໃນລະບົບການຄວບຄຸມສະບັບ (ຕໍ່ໄປນີ້ເອີ້ນວ່າ VCS)
2. ວິທີການຕິດຕາມການປ່ຽນແປງໃນໂຄງສ້າງຖານຂໍ້ມູນຫຼັງຈາກບັນທຶກການຖິ້ມຂີ້ເຫຍື້ອ
3. ວິທີການໂອນການປ່ຽນແປງໃນໂຄງສ້າງຖານຂໍ້ມູນໄປສູ່ສະພາບແວດລ້ອມອື່ນໆໂດຍບໍ່ມີການຂັດແຍ້ງແລະໄຟລ໌ການເຄື່ອນຍ້າຍຍັກໃຫຍ່
4. ວິທີການຈັດຂະບວນການເຮັດວຽກຂະຫນານໃນໂຄງການໂດຍນັກພັດທະນາຈໍານວນຫນຶ່ງ
5. ວິທີການນໍາໃຊ້ຢ່າງປອດໄພການປ່ຽນແປງໂຄງສ້າງຖານຂໍ້ມູນໄປສູ່ສະພາບແວດລ້ອມການຜະລິດ
   

   SchemaKeeper ອອກແບບມາເພື່ອເຮັດວຽກກັບຂັ້ນຕອນການເກັບຮັກສາທີ່ຂຽນເປັນພາສາ PL/pgSQL. ການທົດສອບກັບພາສາອື່ນໆບໍ່ໄດ້ດໍາເນີນການ, ດັ່ງນັ້ນການນໍາໃຊ້ອາດຈະບໍ່ມີປະສິດທິພາບຫຼືອາດຈະບໍ່ເປັນໄປໄດ້.

ວິທີການເກັບຮັກສາໂຄງສ້າງຖານຂໍ້ມູນ dump ໃນ VCS

ຫ້ອງສະຫມຸດ schema-keeper ສະຫນອງຫນ້າທີ່ saveDump, ເຊິ່ງບັນທຶກໂຄງສ້າງຂອງວັດຖຸທັງຫມົດຈາກຖານຂໍ້ມູນເປັນໄຟລ໌ຂໍ້ຄວາມແຍກຕ່າງຫາກ. ຜົນຜະລິດແມ່ນໄດເລກະທໍລີທີ່ມີໂຄງສ້າງຖານຂໍ້ມູນ, ແບ່ງອອກເປັນໄຟລ໌ກຸ່ມທີ່ສາມາດຖືກເພີ່ມເຂົ້າໃນ VCS ໄດ້ຢ່າງງ່າຍດາຍ.

ມາເບິ່ງການແປງວັດຖຸຈາກຖານຂໍ້ມູນເປັນໄຟລ໌ໂດຍໃຊ້ຕົວຢ່າງຫຼາຍອັນ:

ປະເພດວັດຖຸ
ໂຄງການ
Title
ເສັ້ນທາງທີ່ກ່ຽວຂ້ອງເພື່ອຍື່ນ

ຕາຕະລາງ
ສາທາລະນະ
ບັນຊີ
./public/tables/accounts.txt

ຂັ້ນຕອນການເກັບຮັກສາ
ສາທາລະນະ
auth(hash bigint)
./public/functions/auth(int8).sql

ການນໍາສະເຫນີ
ຈອງ
ອັດຕາພາສີ
./booking/views/tariffs.txt

ເນື້ອໃນຂອງໄຟລ໌ແມ່ນການເປັນຕົວແທນຂອງໂຄງສ້າງຂອງວັດຖຸຖານຂໍ້ມູນສະເພາະ. ຕົວຢ່າງ, ສໍາລັບຂັ້ນຕອນການເກັບຮັກສາ, ເນື້ອໃນຂອງໄຟລ໌ຈະເປັນຄໍານິຍາມອັນເຕັມທີ່ຂອງຂັ້ນຕອນການເກັບຮັກສາ, ເລີ່ມຕົ້ນດ້ວຍຕັນ. CREATE OR REPLACE FUNCTION.

ດັ່ງທີ່ເຫັນໄດ້ຈາກຕາຕະລາງຂ້າງເທິງ, ເສັ້ນທາງໄປຫາໄຟລ໌ເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບປະເພດ, schema ແລະຊື່ຂອງວັດຖຸ. ວິທີການນີ້ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການນໍາທາງຜ່ານ dump ແລະການທົບທວນຄືນລະຫັດຂອງການປ່ຽນແປງໃນຖານຂໍ້ມູນ.

ນາມສະກຸນ .sql ສໍາລັບໄຟລ໌ທີ່ມີລະຫັດແຫຼ່ງຂັ້ນຕອນການເກັບຮັກສາ, ມັນຖືກເລືອກເພື່ອໃຫ້ IDE ອັດຕະໂນມັດສະຫນອງເຄື່ອງມືສໍາລັບການພົວພັນກັບຖານຂໍ້ມູນເມື່ອໄຟລ໌ຖືກເປີດ.

ວິທີການຕິດຕາມການປ່ຽນແປງໃນໂຄງສ້າງຖານຂໍ້ມູນຫຼັງຈາກບັນທຶກການຖິ້ມຂີ້ເຫຍື້ອ

ໂດຍການບັນທຶກການຖິ້ມຂີ້ເຫຍື້ອຂອງໂຄງສ້າງຖານຂໍ້ມູນໃນປະຈຸບັນໃນ VCS, ພວກເຮົາໄດ້ຮັບໂອກາດທີ່ຈະກວດເບິ່ງວ່າມີການປ່ຽນແປງໂຄງສ້າງຖານຂໍ້ມູນຫຼັງຈາກ dump ຖືກສ້າງຂຶ້ນ. ໃນຫ້ອງສະຫມຸດ schema-keeper ເພື່ອກວດຫາການປ່ຽນແປງໃນໂຄງສ້າງຖານຂໍ້ມູນ, ມີຫນ້າທີ່ສະຫນອງໃຫ້ verifyDump, ເຊິ່ງສົ່ງຄືນຂໍ້ມູນກ່ຽວກັບຄວາມແຕກຕ່າງໂດຍບໍ່ມີຜົນຂ້າງຄຽງ.

ວິທີທາງເລືອກໃນການກວດສອບແມ່ນການໂທຫາຟັງຊັນອີກເທື່ອຫນຶ່ງ saveDump, ການລະບຸໄດເລກະທໍລີດຽວກັນ, ແລະກວດເບິ່ງໃນ VCS ສໍາລັບການປ່ຽນແປງ. ເນື່ອງຈາກວັດຖຸທັງໝົດຈາກຖານຂໍ້ມູນຖືກບັນທຶກໄວ້ໃນໄຟລ໌ແຍກຕ່າງຫາກ, VCS ຈະສະແດງພຽງແຕ່ວັດຖຸທີ່ມີການປ່ຽນແປງ.
ຂໍ້ເສຍຫຼັກຂອງວິທີການນີ້ແມ່ນຄວາມຕ້ອງການທີ່ຈະຂຽນທັບໄຟລ໌ເພື່ອເບິ່ງການປ່ຽນແປງ.

ວິທີການໂອນການປ່ຽນແປງໃນໂຄງສ້າງຖານຂໍ້ມູນໄປສູ່ສະພາບແວດລ້ອມອື່ນໆໂດຍບໍ່ມີການຂັດແຍ້ງແລະໄຟລ໌ການເຄື່ອນຍ້າຍຍັກໃຫຍ່

ຂໍຂອບໃຈກັບຫນ້າທີ່ deployDump ລະຫັດແຫຼ່ງຂອງຂັ້ນຕອນການເກັບຮັກສາສາມາດຖືກແກ້ໄຂໃນແບບດຽວກັນກັບລະຫັດແຫຼ່ງຄໍາຮ້ອງສະຫມັກປົກກະຕິ. ທ່ານ​ສາ​ມາດ​ເພີ່ມ / ລຶບ​ເສັ້ນ​ໃຫມ່​ໃນ​ລະ​ຫັດ​ຂັ້ນ​ຕອນ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​ແລະ​ການ​ປ່ຽນ​ແປງ​ໃນ​ທັນ​ທີ​ການ​ຄວບ​ຄຸມ​ສະ​ບັບ​, ຫຼື​ສ້າງ / ລຶບ​ຂັ້ນ​ຕອນ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​ໂດຍ​ການ​ສ້າງ / ລຶບ​ໄຟລ​໌​ທີ່​ສອດ​ຄ້ອງ​ກັນ​ໃນ​ການ dump directory​.

ຕົວຢ່າງ, ເພື່ອສ້າງຂັ້ນຕອນການເກັບຮັກສາໃຫມ່ໃນ schema public ພຽງແຕ່ສ້າງໄຟລ໌ໃຫມ່ທີ່ມີນາມສະກຸນ .sql ໃນ​ລະ​ບົບ​ public/functions, ເອົາລະຫັດແຫຼ່ງຂອງຂັ້ນຕອນການເກັບຮັກສາໄວ້ໃນມັນ, ລວມທັງບລັອກ CREATE OR REPLACE FUNCTION, ຫຼັງຈາກນັ້ນໂທຫາຫນ້າທີ່ deployDump. ການແກ້ໄຂແລະການລຶບຂັ້ນຕອນທີ່ເກັບໄວ້ແມ່ນເກີດຂື້ນໃນແບບດຽວກັນ. ດັ່ງນັ້ນ, ລະຫັດເຂົ້າໄປໃນທັງ VCS ແລະຖານຂໍ້ມູນໃນເວລາດຽວກັນ.

ຖ້າ​ຫາກ​ວ່າ​ຄວາມ​ຜິດ​ພາດ​ປາ​ກົດ​ຂຶ້ນ​ໃນ​ລະ​ຫັດ​ແຫຼ່ງ​ຂໍ້​ມູນ​ຂອງ​ຂັ້ນ​ຕອນ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​, ຫຼື​ຄວາມ​ແຕກ​ຕ່າງ​ລະ​ຫວ່າງ​ຊື່​ຂອງ​ໄຟລ​໌​ແລະ​ຂັ້ນ​ຕອນ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​, ຫຼັງ​ຈາກ​ນັ້ນ​. deployDump ຈະລົ້ມເຫລວ, ສະແດງຂໍ້ຄວາມສະແດງຂໍ້ຜິດພາດ. ບໍ່ກົງກັນຂອງຂັ້ນຕອນການເກັບຮັກສາລະຫວ່າງ dump ແລະຖານຂໍ້ມູນປະຈຸບັນແມ່ນເປັນໄປບໍ່ໄດ້ໃນເວລາທີ່ການນໍາໃຊ້ deployDump.

ເມື່ອສ້າງຂັ້ນຕອນການເກັບຮັກສາໃຫມ່, ບໍ່ຈໍາເປັນຕ້ອງໃສ່ຊື່ໄຟລ໌ທີ່ຖືກຕ້ອງດ້ວຍຕົນເອງ. ມັນພຽງພໍສໍາລັບໄຟລ໌ທີ່ຈະມີການຂະຫຍາຍ .sql. ຫຼັງຈາກໂທ deployDump ຂໍ້ຄວາມຂໍ້ຜິດພາດຈະມີຊື່ທີ່ຖືກຕ້ອງ, ເຊິ່ງສາມາດໃຊ້ເພື່ອປ່ຽນຊື່ໄຟລ໌.

deployDump ອະນຸຍາດໃຫ້ທ່ານປ່ຽນພາລາມິເຕີຂອງຫນ້າທີ່ຫຼືປະເພດກັບຄືນໂດຍບໍ່ມີການປະຕິບັດເພີ່ມເຕີມ, ໃນຂະນະທີ່ມີວິທີການຄລາສສິກທີ່ເຈົ້າຈະຕ້ອງ.
ປະຕິບັດກ່ອນ DROP FUNCTION, ແລະພຽງແຕ່ຫຼັງຈາກນັ້ນ CREATE OR REPLACE FUNCTION.

ແຕ່ຫນ້າເສຍດາຍ, ມີບາງສະຖານະການ deployDump ບໍ່ສາມາດນຳໃຊ້ການປ່ຽນແປງອັດຕະໂນມັດໄດ້. ຕົວຢ່າງ, ຖ້າຟັງຊັນ trigger ທີ່ຖືກນໍາໃຊ້ໂດຍຢ່າງຫນ້ອຍຫນຶ່ງ trigger ຖືກໂຍກຍ້າຍ. ສະຖານະການດັ່ງກ່າວຖືກແກ້ໄຂດ້ວຍຕົນເອງໂດຍໃຊ້ໄຟລ໌ການເຄື່ອນຍ້າຍ.

ຖ້າເຈົ້າຮັບຜິດຊອບໃນການເຄື່ອນຍ້າຍການປ່ຽນແປງຂັ້ນຕອນການເກັບຮັກສາ schema-keeper, ຫຼັງຈາກນັ້ນໄຟລ໌ການເຄື່ອນຍ້າຍຕ້ອງຖືກນໍາໃຊ້ເພື່ອໂອນການປ່ຽນແປງອື່ນໆໃນໂຄງສ້າງ. ຕົວຢ່າງ, ຫ້ອງສະຫມຸດທີ່ດີສໍາລັບການເຮັດວຽກກັບການເຄື່ອນຍ້າຍແມ່ນ ຄໍາສອນ / ການເຄື່ອນຍ້າຍ.

ການໂອນຍ້າຍຕ້ອງຖືກນໍາໃຊ້ກ່ອນທີ່ຈະເປີດຕົວ deployDump. ນີ້ອະນຸຍາດໃຫ້ທ່ານເຮັດການປ່ຽນແປງໂຄງສ້າງທັງຫມົດແລະແກ້ໄຂສະຖານະການທີ່ມີບັນຫາເພື່ອໃຫ້ການປ່ຽນແປງໃນຂັ້ນຕອນການເກັບຮັກສາໄດ້ຖືກໂອນຕໍ່ມາໂດຍບໍ່ມີບັນຫາ.

ການເຮັດວຽກກັບການເຄື່ອນຍ້າຍຈະຖືກອະທິບາຍໃນລາຍລະອຽດເພີ່ມເຕີມໃນພາກຕໍ່ໄປນີ້.

ວິທີການຈັດຂະບວນການເຮັດວຽກຂະຫນານໃນໂຄງການໂດຍນັກພັດທະນາຈໍານວນຫນຶ່ງ

ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະສ້າງສະຄິບສໍາລັບການເລີ່ມຕົ້ນທີ່ສົມບູນຂອງຖານຂໍ້ມູນ, ເຊິ່ງຈະຖືກເປີດຕົວໂດຍນັກພັດທະນາໃນເຄື່ອງເຮັດວຽກຂອງລາວ, ນໍາເອົາໂຄງສ້າງຂອງຖານຂໍ້ມູນທ້ອງຖິ່ນໃຫ້ສອດຄ່ອງກັບການຖິ້ມຂີ້ເຫຍື້ອທີ່ບັນທຶກໄວ້ໃນ VCS. ວິທີທີ່ງ່າຍທີ່ສຸດແມ່ນການແບ່ງການເລີ່ມຕົ້ນຂອງຖານຂໍ້ມູນທ້ອງຖິ່ນອອກເປັນ 3 ຂັ້ນຕອນ:

1. ນໍາເຂົ້າໄຟລ໌ທີ່ມີໂຄງສ້າງພື້ນຖານທີ່ຈະຖືກເອີ້ນວ່າ e.g. base.sql
2. ນຳໃຊ້ການຍ້າຍຖິ່ນຖານ
3. ທ້າທາຍ deployDump

base.sql ແມ່ນຈຸດເລີ່ມຕົ້ນຢູ່ເທິງສຸດຂອງການເຄື່ອນຍ້າຍທີ່ຖືກນໍາໃຊ້ແລະປະຕິບັດ deployDump, ວ່າແມ່ນ base.sql + миграции + deployDump = актуальная структура БД. ທ່ານສາມາດສ້າງໄຟລ໌ດັ່ງກ່າວໂດຍໃຊ້ປະໂຫຍດ pg_dump. ໃຊ້ແລ້ວ base.sql ສະເພາະເມື່ອເລີ່ມຕົ້ນຖານຂໍ້ມູນຕັ້ງແຕ່ເລີ່ມຕົ້ນ.

ໃຫ້ໂທຫາ script ສໍາລັບການເລີ່ມຕົ້ນຖານຂໍ້ມູນທີ່ສົມບູນ refresh.sh. ຂັ້ນຕອນການເຮັດວຽກອາດຈະເບິ່ງຄືວ່ານີ້:

1. ນັກພັດທະນາເປີດຕົວໃນສະພາບແວດລ້ອມຂອງລາວ refresh.sh ແລະໄດ້ຮັບໂຄງສ້າງຖານຂໍ້ມູນໃນປະຈຸບັນ
2. ນັກພັດທະນາເລີ່ມຕົ້ນເຮັດວຽກຢູ່ໃນມື, ດັດແກ້ຖານຂໍ້ມູນທ້ອງຖິ່ນເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການຂອງຫນ້າທີ່ໃຫມ່ (ALTER TABLE ... ADD COLUMN ແລະອື່ນໆ)
3. ຫຼັງຈາກສໍາເລັດວຽກງານ, ນັກພັດທະນາໂທຫາຫນ້າທີ່ saveDumpເພື່ອເຮັດການປ່ຽນແປງໃນຖານຂໍ້ມູນໃນ VCS
4. ເປີດຕົວນັກພັດທະນາຄືນໃໝ່ refresh.sh, ຫຼັງຈາກນັ້ນ, verifyDumpເຊິ່ງຕອນນີ້ສະແດງລາຍຊື່ການປ່ຽນແປງທີ່ຈະລວມເຂົ້າໃນການເຄື່ອນຍ້າຍ
5. ນັກພັດທະນາໂອນການປ່ຽນແປງໂຄງສ້າງທັງຫມົດໄປຫາໄຟລ໌ການເຄື່ອນຍ້າຍ, ດໍາເນີນການອີກເທື່ອຫນຶ່ງ refresh.sh и verifyDump, ແລະ, ຖ້າການເຄື່ອນຍ້າຍໄດ້ຖືກລວບລວມຢ່າງຖືກຕ້ອງ, verifyDump ຈະບໍ່ສະແດງຄວາມແຕກຕ່າງລະຫວ່າງຖານຂໍ້ມູນທ້ອງຖິ່ນແລະ dump ທີ່ບັນທຶກໄວ້

ຂະບວນການທີ່ອະທິບາຍຂ້າງເທິງແມ່ນເຂົ້າກັນໄດ້ກັບຫຼັກການ gitflow. ແຕ່ລະສາຂາໃນ VCS ຈະມີສະບັບຂອງຕົນເອງຂອງ dump, ແລະໃນເວລາທີ່ການລວມສາຂາ, dumps ຈະຖືກລວມເຂົ້າກັນ. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ບໍ່ຈໍາເປັນຕ້ອງດໍາເນີນການເພີ່ມເຕີມຫຼັງຈາກການລວມຕົວ, ແຕ່ຖ້າມີການປ່ຽນແປງໃນສາຂາທີ່ແຕກຕ່າງກັນ, ຕົວຢ່າງ, ຢູ່ໃນຕາຕະລາງດຽວກັນ, ຄວາມຂັດແຍ້ງອາດຈະເກີດຂື້ນ.

ໃຫ້ພິຈາລະນາສະຖານະການຂັດແຍ້ງໂດຍໃຊ້ຕົວຢ່າງ: ມີສາຂາ ພັດທະນາຊຶ່ງ​ຈາກ​ສອງ​ສາ​ຂາ​: feature1 и feature2, ທີ່ບໍ່ມີຂໍ້ຂັດແຍ່ງກັບ ພັດທະນາ, ແຕ່ມີຄວາມຂັດແຍ້ງກັບກັນແລະກັນ. ວຽກງານແມ່ນເພື່ອລວມສາຂາທັງສອງເຂົ້າໄປໃນ ພັດທະນາ. ສໍາລັບກໍລະນີນີ້, ແນະນໍາໃຫ້ທໍາອິດປະສົມປະສານຫນຶ່ງຂອງສາຂາເຂົ້າໄປໃນ ພັດທະນາແລະ​ຫຼັງ​ຈາກ​ນັ້ນ​ລວມ​ ພັດທະນາ ກັບສາຂາທີ່ຍັງເຫຼືອ, ແກ້ໄຂຂໍ້ຂັດແຍ່ງໃນສາຂາທີ່ຍັງເຫຼືອ, ແລະຫຼັງຈາກນັ້ນລວມສາຂາສຸດທ້າຍເຂົ້າໄປໃນ ພັດທະນາ. ໃນລະຫວ່າງໄລຍະການແກ້ໄຂຂໍ້ຂັດແຍ່ງ, ທ່ານອາດຈະຕ້ອງແກ້ໄຂໄຟລ໌ການເຄື່ອນຍ້າຍໃນສາຂາສຸດທ້າຍເພື່ອໃຫ້ມັນກົງກັບ dump ສຸດທ້າຍ, ເຊິ່ງລວມມີຜົນຂອງການລວມຕົວ.

ວິທີການນໍາໃຊ້ຢ່າງປອດໄພການປ່ຽນແປງໂຄງສ້າງຖານຂໍ້ມູນໄປສູ່ສະພາບແວດລ້ອມການຜະລິດ

ຂໍຂອບໃຈກັບການມີ dump ຂອງໂຄງສ້າງຖານຂໍ້ມູນໃນປະຈຸບັນໃນ VCS, ມັນເປັນໄປໄດ້ທີ່ຈະກວດສອບຖານຂໍ້ມູນການຜະລິດສໍາລັບການປະຕິບັດຕາມທີ່ແນ່ນອນກັບໂຄງສ້າງທີ່ກໍານົດໄວ້. ນີ້ຮັບປະກັນວ່າການປ່ຽນແປງທັງຫມົດທີ່ຜູ້ພັດທະນາມີຈຸດປະສົງໄດ້ຖືກໂອນໄປສູ່ພື້ນຖານການຜະລິດຢ່າງສໍາເລັດຜົນ.

ນັບ​ຕັ້ງ​ແຕ່ ດີນ ໃນ PostgreSQL ແມ່ນ ທຸລະກຳ, ແນະນໍາໃຫ້ປະຕິບັດຕາມຄໍາສັ່ງຂອງການຕິດຕັ້ງຕໍ່ໄປນີ້, ດັ່ງນັ້ນ, ໃນກໍລະນີທີ່ມີຄວາມຜິດພາດທີ່ບໍ່ຄາດຄິດ, ທ່ານສາມາດດໍາເນີນການ "ບໍ່ເຈັບປວດ" ໄດ້. ROLLBACK:

1. ເລີ່ມທຸລະກໍາ
2. ປະຕິບັດການເຄື່ອນຍ້າຍທັງຫມົດໃນທຸລະກໍາ
3. ໃນການເຮັດທຸລະກໍາດຽວກັນ, ດໍາເນີນການ deployDump
4. ໂດຍບໍ່ມີການສໍາເລັດການເຮັດທຸລະກໍາ, ດໍາເນີນການ verifyDump. ຖ້າບໍ່ມີຂໍ້ຜິດພາດ, ດໍາເນີນການ COMMIT. ຖ້າມີຂໍ້ຜິດພາດ, ດໍາເນີນການ ROLLBACK

ຂັ້ນຕອນເຫຼົ່ານີ້ສາມາດຖືກລວມເຂົ້າກັນໄດ້ຢ່າງງ່າຍດາຍໃນວິທີການທີ່ມີຢູ່ເພື່ອນຳໃຊ້ແອັບພລິເຄຊັນ, ລວມທັງເວລາສູນລົງ.

ສະຫລຸບ

ຂໍຂອບໃຈກັບວິທີການທີ່ອະທິບາຍຂ້າງເທິງ, ມັນເປັນໄປໄດ້ທີ່ຈະບີບປະສິດທິພາບສູງສຸດອອກຈາກໂຄງການ "PHP + PostgreSQL", ໃນຂະນະທີ່ການເສຍສະລະຄວາມສະດວກໃນການພັດທະນາຂ້ອນຂ້າງຫນ້ອຍເມື່ອທຽບກັບການປະຕິບັດທຸກເຫດຜົນທາງທຸລະກິດໃນລະຫັດຄໍາຮ້ອງສະຫມັກຕົ້ນຕໍ. ຍິ່ງໄປກວ່ານັ້ນ, ການປະມວນຜົນຂໍ້ມູນໃນ PL/pgSQL ມັກຈະມີຄວາມໂປ່ງໃສແລະຕ້ອງການລະຫັດຫນ້ອຍກວ່າການເຮັດວຽກດຽວກັນທີ່ຂຽນໃນ PHP.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com