วัตถุประสงค์ของบทความนี้คือการใช้ตัวอย่างของห้องสมุด ผู้รักษาสคีมา แสดงเครื่องมือที่ช่วยลดความซับซ้อนของกระบวนการพัฒนาฐานข้อมูลภายในโครงการ PHP โดยใช้ PostgreSQL DBMS

ประการแรกข้อมูลจากบทความนี้จะเป็นประโยชน์สำหรับนักพัฒนาที่ต้องการใช้ประโยชน์สูงสุดจากความสามารถของ PostgreSQL แต่ประสบปัญหาในการรักษาตรรกะทางธุรกิจไว้ในฐานข้อมูล

บทความนี้จะไม่อธิบายข้อดีหรือข้อเสียของการจัดเก็บตรรกะทางธุรกิจในฐานข้อมูล สันนิษฐานว่าผู้อ่านได้เลือกแล้ว

คำถามต่อไปนี้จะได้รับการพิจารณา:

1. ดัมพ์โครงสร้างฐานข้อมูลควรจัดเก็บในรูปแบบใดในระบบควบคุมเวอร์ชัน (ต่อไปนี้จะเรียกว่า VCS)
2. วิธีติดตามการเปลี่ยนแปลงในโครงสร้างฐานข้อมูลหลังจากบันทึกดัมพ์
3. วิธีถ่ายโอนการเปลี่ยนแปลงในโครงสร้างฐานข้อมูลไปยังสภาพแวดล้อมอื่นโดยไม่มีข้อขัดแย้งและไฟล์การโยกย้ายขนาดยักษ์
4. วิธีจัดระเบียบกระบวนการทำงานแบบขนานในโครงการโดยนักพัฒนาหลายคน
5. วิธีปรับใช้การเปลี่ยนแปลงเพิ่มเติมในโครงสร้างฐานข้อมูลกับสภาพแวดล้อมการใช้งานจริงอย่างปลอดภัย
   

   SchemaKeeper ออกแบบมาเพื่อทำงานกับขั้นตอนการจัดเก็บที่เขียนด้วยภาษา PL/pgSQL. ยังไม่มีการทดสอบกับภาษาอื่น ดังนั้น การใช้งานอาจไม่ได้ผลเท่าที่ควรหรืออาจไม่สามารถทำได้

วิธีจัดเก็บดัมพ์โครงสร้างฐานข้อมูลใน VCS

ห้องสมุด ผู้รักษาสคีมา มีฟังก์ชัน saveDumpซึ่งจะบันทึกโครงสร้างของออบเจ็กต์ทั้งหมดจากฐานข้อมูลเป็นไฟล์ข้อความแยกกัน ผลลัพธ์คือไดเร็กทอรีที่มีโครงสร้างฐานข้อมูล ซึ่งแบ่งออกเป็นไฟล์ที่จัดกลุ่มซึ่งสามารถเพิ่มลงใน VCS ได้อย่างง่ายดาย

ลองดูที่การแปลงวัตถุจากฐานข้อมูลเป็นไฟล์โดยใช้หลายตัวอย่าง:

ประเภทวัตถุ
โครงการนี้
ชื่อ
เส้นทางสัมพันธ์กับไฟล์

ตาราง
สาธารณะ
บัญชี
./public/tables/accounts.txt

ขั้นตอนการเก็บ
สาธารณะ
รับรองความถูกต้อง (แฮชใหญ่)
./public/functions/auth(int8).sql

ความคิด
การจอง
อัตราภาษีศุลกากร
./booking/views/tariffs.txt

เนื้อหาของไฟล์เป็นตัวแทนข้อความของโครงสร้างของวัตถุฐานข้อมูลเฉพาะ ตัวอย่างเช่น สำหรับขั้นตอนการจัดเก็บ เนื้อหาของไฟล์จะเป็นคำจำกัดความที่สมบูรณ์ของขั้นตอนการจัดเก็บ โดยเริ่มจากบล็อก CREATE OR REPLACE FUNCTION.

ดังที่เห็นได้จากตารางด้านบน เส้นทางไปยังไฟล์จะเก็บข้อมูลเกี่ยวกับประเภท สคีมา และชื่อของออบเจ็กต์ แนวทางนี้ทำให้ง่ายต่อการนำทางผ่านดัมพ์และการตรวจทานโค้ดของการเปลี่ยนแปลงในฐานข้อมูล

นามสกุล .sql สำหรับไฟล์ที่มีซอร์สโค้ดของ Stored Procedure จะถูกเลือกเพื่อให้ IDE มีเครื่องมือสำหรับการโต้ตอบกับฐานข้อมูลโดยอัตโนมัติเมื่อเปิดไฟล์

วิธีติดตามการเปลี่ยนแปลงในโครงสร้างฐานข้อมูลหลังจากบันทึกดัมพ์

ด้วยการบันทึกดัมพ์ของโครงสร้างฐานข้อมูลปัจจุบันใน VCS เราจะได้รับโอกาสในการตรวจสอบว่ามีการเปลี่ยนแปลงโครงสร้างฐานข้อมูลหรือไม่หลังจากสร้างดัมพ์แล้ว ในห้องสมุด ผู้รักษาสคีมา เพื่อตรวจจับการเปลี่ยนแปลงในโครงสร้างฐานข้อมูลจะมีการจัดเตรียมฟังก์ชันไว้ verifyDumpซึ่งส่งคืนข้อมูลเกี่ยวกับความแตกต่างโดยไม่มีผลข้างเคียง

อีกวิธีหนึ่งในการตรวจสอบคือการเรียกใช้ฟังก์ชันอีกครั้ง saveDumpระบุไดเร็กทอรีเดียวกัน และตรวจสอบใน VCS เพื่อดูการเปลี่ยนแปลง เนื่องจากวัตถุทั้งหมดจากฐานข้อมูลถูกบันทึกเป็นไฟล์แยกกัน VCS จะแสดงเฉพาะวัตถุที่เปลี่ยนแปลงเท่านั้น
ข้อเสียเปรียบหลักของวิธีนี้คือจำเป็นต้องเขียนทับไฟล์เพื่อดูการเปลี่ยนแปลง

วิธีถ่ายโอนการเปลี่ยนแปลงในโครงสร้างฐานข้อมูลไปยังสภาพแวดล้อมอื่นโดยไม่มีข้อขัดแย้งและไฟล์การโยกย้ายขนาดยักษ์

ขอบคุณฟังก์ชัน deployDump ซอร์สโค้ดของขั้นตอนการจัดเก็บสามารถแก้ไขได้ในลักษณะเดียวกับซอร์สโค้ดของแอปพลิเคชันปกติทุกประการ คุณสามารถเพิ่ม/ลบบรรทัดใหม่ในโค้ดขั้นตอนการจัดเก็บและผลักดันการเปลี่ยนแปลงไปยังการควบคุมเวอร์ชันได้ทันที หรือสร้าง/ลบขั้นตอนการจัดเก็บโดยการสร้าง/ลบไฟล์ที่เกี่ยวข้องในไดเร็กทอรีดัมพ์

ตัวอย่างเช่น เมื่อต้องการสร้างขั้นตอนการจัดเก็บใหม่ในสคีมา public เพียงสร้างไฟล์ใหม่ที่มีนามสกุล .sql ในไดเรกทอรี public/functionsให้วางซอร์สโค้ดของโพรซีเดอร์ที่เก็บไว้ไว้ในนั้น รวมถึงบล็อกด้วย CREATE OR REPLACE FUNCTIONแล้วเรียกใช้ฟังก์ชัน deployDump. การแก้ไขและการลบขั้นตอนการจัดเก็บเกิดขึ้นในลักษณะเดียวกัน ดังนั้นโค้ดจะเข้าสู่ทั้ง VCS และฐานข้อมูลในเวลาเดียวกัน

หากมีข้อผิดพลาดปรากฏในซอร์สโค้ดของขั้นตอนการจัดเก็บใด ๆ หรือความแตกต่างระหว่างชื่อไฟล์และขั้นตอนการจัดเก็บ deployDump จะล้มเหลวโดยแสดงข้อความแสดงข้อผิดพลาด กระบวนการจัดเก็บที่ไม่ตรงกันระหว่างดัมพ์และฐานข้อมูลปัจจุบันเป็นไปไม่ได้เมื่อใช้งาน deployDump.

เมื่อสร้างขั้นตอนการจัดเก็บใหม่ ไม่จำเป็นต้องป้อนชื่อไฟล์ที่ถูกต้องด้วยตนเอง ไฟล์ต้องมีนามสกุลก็พอแล้ว .sql. หลังจากการโทร deployDump ข้อความแสดงข้อผิดพลาดจะมีชื่อที่ถูกต้องซึ่งสามารถใช้เพื่อเปลี่ยนชื่อไฟล์ได้

deployDump ช่วยให้คุณสามารถเปลี่ยนพารามิเตอร์ของฟังก์ชันหรือประเภทการส่งคืนได้โดยไม่ต้องดำเนินการใดๆ เพิ่มเติม ในขณะที่คุณต้องดำเนินการด้วยวิธีคลาสสิก
ดำเนินการก่อน DROP FUNCTIONและจากนั้นเท่านั้น CREATE OR REPLACE FUNCTION.

น่าเสียดายที่มีบางสถานการณ์ที่ deployDump ไม่สามารถใช้การเปลี่ยนแปลงโดยอัตโนมัติได้ ตัวอย่างเช่น หากฟังก์ชันทริกเกอร์ที่ใช้โดยทริกเกอร์อย่างน้อย XNUMX รายการถูกลบออก สถานการณ์ดังกล่าวได้รับการแก้ไขด้วยตนเองโดยใช้ไฟล์การโยกย้าย

หากคุณมีหน้าที่รับผิดชอบในการโยกย้ายการเปลี่ยนแปลงไปยังขั้นตอนการจัดเก็บ ผู้รักษาสคีมาจากนั้นจะต้องใช้ไฟล์การโยกย้ายเพื่อถ่ายโอนการเปลี่ยนแปลงอื่นๆ ในโครงสร้าง ตัวอย่างเช่น ห้องสมุดที่ดีสำหรับการทำงานกับการโยกย้ายคือ หลักคำสอน/การย้ายถิ่น.

ต้องใช้การย้ายข้อมูลก่อนการเปิดตัว deployDump. สิ่งนี้ช่วยให้คุณสามารถทำการเปลี่ยนแปลงโครงสร้างทั้งหมดและแก้ไขสถานการณ์ที่มีปัญหา เพื่อให้การเปลี่ยนแปลงในกระบวนงานที่เก็บไว้ถูกถ่ายโอนในภายหลังโดยไม่มีปัญหา

การทำงานกับการย้ายข้อมูลจะมีการอธิบายรายละเอียดเพิ่มเติมในส่วนต่อไปนี้

วิธีจัดระเบียบกระบวนการทำงานแบบขนานในโครงการโดยนักพัฒนาหลายคน

จำเป็นต้องสร้างสคริปต์สำหรับการเริ่มต้นฐานข้อมูลโดยสมบูรณ์ ซึ่งนักพัฒนาจะเปิดตัวบนเครื่องทำงานของเขา โดยนำโครงสร้างของฐานข้อมูลท้องถิ่นให้สอดคล้องกับดัมพ์ที่บันทึกไว้ใน VCS วิธีที่ง่ายที่สุดคือการแบ่งการเริ่มต้นฐานข้อมูลท้องถิ่นออกเป็น 3 ขั้นตอน:

1. นำเข้าไฟล์ที่มีโครงสร้างพื้นฐานที่จะเรียกว่าเช่น base.sql
2. การใช้การย้ายข้อมูล
3. โทรศัพท์ deployDump

base.sql เป็นจุดเริ่มต้นนอกเหนือจากการใช้และดำเนินการย้ายข้อมูล deployDumpนั่นคือ base.sql + миграции + deployDump = актуальная структура БД. คุณสามารถสร้างไฟล์ดังกล่าวได้โดยใช้ยูทิลิตี้ pg_dump. ใช้แล้ว base.sql เฉพาะเมื่อเริ่มต้นฐานข้อมูลตั้งแต่เริ่มต้น

มาเรียกสคริปต์เพื่อเตรียมใช้งานฐานข้อมูลให้สมบูรณ์ refresh.sh. ขั้นตอนการทำงานอาจมีลักษณะดังนี้:

1. นักพัฒนาเปิดตัวในสภาพแวดล้อมของเขา refresh.sh และรับโครงสร้างฐานข้อมูลปัจจุบัน
2. นักพัฒนาเริ่มทำงานกับงานที่มีอยู่ โดยแก้ไขฐานข้อมูลในเครื่องเพื่อตอบสนองความต้องการของฟังก์ชันใหม่ (ALTER TABLE ... ADD COLUMN ฯลฯ)
3. หลังจากเสร็จสิ้นภารกิจ นักพัฒนาจะเรียกใช้ฟังก์ชันนี้ saveDumpเพื่อยืนยันการเปลี่ยนแปลงฐานข้อมูลใน VCS
4. นักพัฒนาเปิดตัวอีกครั้ง refresh.shแล้วก็ verifyDumpซึ่งตอนนี้แสดงรายการการเปลี่ยนแปลงที่จะรวมไว้ในการย้ายข้อมูล
5. นักพัฒนาถ่ายโอนการเปลี่ยนแปลงโครงสร้างทั้งหมดไปยังไฟล์การโยกย้าย และรันอีกครั้ง refresh.sh и verifyDumpและหากการรวบรวมการโยกย้ายถูกต้อง verifyDump จะไม่แสดงความแตกต่างระหว่างฐานข้อมูลในเครื่องและดัมพ์ที่บันทึกไว้

กระบวนการที่อธิบายไว้ข้างต้นเข้ากันได้กับหลักการ gitflow แต่ละสาขาใน VCS จะมีเวอร์ชันของดัมพ์ของตัวเอง และเมื่อรวมสาขา ดัมพ์จะถูกรวมเข้าด้วยกัน ในกรณีส่วนใหญ่ ไม่จำเป็นต้องดำเนินการเพิ่มเติมหลังจากการผสาน แต่หากมีการเปลี่ยนแปลงในสาขาที่แตกต่างกัน เช่น ในตารางเดียวกัน อาจเกิดข้อขัดแย้งได้

ลองพิจารณาสถานการณ์ความขัดแย้งโดยใช้ตัวอย่าง: มีสาขาอยู่ พัฒนาซึ่งมี XNUMX สาขา ดังนี้ feature1 и feature2ซึ่งไม่มีความขัดแย้งกับ พัฒนาแต่มีความขัดแย้งกัน ภารกิจคือการรวมทั้งสองสาขาเข้าด้วยกัน พัฒนา. ในกรณีนี้ ขอแนะนำให้รวมสาขาใดสาขาหนึ่งเข้าด้วยกันก่อน พัฒนาแล้วจึงผสาน พัฒนา ไปสู่สาขาที่เหลือ แก้ไขปัญหาความขัดแย้งในสาขาที่เหลือ แล้วรวมสาขาสุดท้ายเข้าด้วยกัน พัฒนา. ในระหว่างขั้นตอนการแก้ไขข้อขัดแย้ง คุณอาจต้องแก้ไขไฟล์การโยกย้ายในสาขาสุดท้ายเพื่อให้ตรงกับการถ่ายโอนข้อมูลขั้นสุดท้าย ซึ่งรวมถึงผลลัพธ์ของการผสาน

วิธีปรับใช้การเปลี่ยนแปลงเพิ่มเติมในโครงสร้างฐานข้อมูลกับสภาพแวดล้อมการใช้งานจริงอย่างปลอดภัย

ด้วยการมีดัมพ์ของโครงสร้างฐานข้อมูลปัจจุบันใน VCS ทำให้สามารถตรวจสอบฐานข้อมูลการผลิตว่าสอดคล้องกับโครงสร้างที่ต้องการอย่างแน่นอน เพื่อให้แน่ใจว่าการเปลี่ยนแปลงทั้งหมดที่นักพัฒนาตั้งใจไว้จะถูกโอนไปยังฐานการผลิตได้สำเร็จ

ในขณะที่ DDL ใน PostgreSQL คือ การทำธุรกรรมขอแนะนำให้ปฏิบัติตามลำดับการใช้งานต่อไปนี้ เพื่อที่ว่าในกรณีที่เกิดข้อผิดพลาดที่ไม่คาดคิด คุณสามารถดำเนินการ "อย่างไม่ลำบาก" ROLLBACK:

1. เริ่มการทำธุรกรรม
2. ดำเนินการย้ายข้อมูลทั้งหมดในธุรกรรม
3. ในธุรกรรมเดียวกัน ให้ดำเนินการ deployDump
4. ดำเนินการโดยไม่ต้องทำธุรกรรมให้เสร็จสิ้น verifyDump. หากไม่มีข้อผิดพลาดให้เรียกใช้ COMMIT. หากมีข้อผิดพลาดให้เรียกใช้ ROLLBACK

ขั้นตอนเหล่านี้สามารถรวมเข้ากับแนวทางการใช้งานแอปพลิเคชันที่มีอยู่ได้อย่างง่ายดาย รวมถึงการหยุดทำงานเป็นศูนย์

ข้อสรุป

ด้วยวิธีการที่อธิบายไว้ข้างต้น คุณสามารถบีบประสิทธิภาพสูงสุดออกจากโปรเจ็กต์ “PHP + PostgreSQL” ได้ ในขณะที่สูญเสียความสะดวกในการพัฒนาค่อนข้างน้อยเมื่อเทียบกับการใช้ตรรกะทางธุรกิจทั้งหมดในโค้ดแอปพลิเคชันหลัก อีกทั้งการประมวลผลข้อมูลใน PL/pgSQL มักจะดูโปร่งใสกว่าและต้องใช้โค้ดน้อยกว่าฟังก์ชันเดียวกันที่เขียนด้วย PHP

ที่มา: will.com