الغرض من هذه المقالة هو استخدام مكتبة حافظة المخططات كمثال لإظهار الأدوات لتبسيط تطوير قاعدة البيانات في مشاريع PHP باستخدام PostgreSQL DBMSs.

سيتم تناول المشكلات التالية:

1. في أي شكل لتخزين تفريغ بنية قاعدة البيانات في نظام التحكم في الإصدار (يشار إليه فيما يلي - VCS)
2. كيفية تعقب التغييرات في بنية قاعدة البيانات بعد حفظ التفريغ
3. كيفية نقل التغييرات في بنية قاعدة البيانات إلى بيئات أخرى دون تعارضات وملفات الترحيل العملاقة
4. كيفية تأسيس عملية عمل متوازي على مشروع من قبل العديد من المطورين
5. كيفية نشر المزيد من التغييرات بأمان إلى بنية قاعدة البيانات إلى بيئة الإنتاج

ستكون المعلومات الواردة في هذه المقالة مفيدة للمطورين الذين يريدون الاستفادة إلى أقصى حد من قدرات PostgreSQL ، لكنهم يواجهون مشاكل في الحفاظ على منطق العمل في قاعدة البيانات.

لن تصف المقالة مزايا أو عيوب تخزين منطق الأعمال في قاعدة بيانات. من المفترض أن يكون القارئ قد تم بالفعل الاختيار.

تم تصميم SchemaKeeper للعمل مع الإجراءات المخزنة المكتوبة في PL / pgSQL . لم يتم إجراء الاختبار بلغات أخرى ، لذلك قد لا يكون الاستخدام فعالًا أو مستحيلًا.

في أي شكل لتخزين تفريغ بنية قاعدة البيانات في VCS

توفر مكتبة مخطط الحفظ وظيفة saveDump ، التي تحفظ بنية الكائنات من قاعدة البيانات كملفات نصية منفصلة. يقوم الإخراج بإنشاء دليل يحتوي على بنية قاعدة البيانات ، مقسمة إلى ملفات مجمعة يسهل إضافتها إلى VCS.

ضع في اعتبارك تحويل الكائنات من قاعدة بيانات إلى ملفات مع بعض الأمثلة:

محتوى الملف هو تمثيل نصي لبنية كائن قاعدة بيانات محددة. على سبيل المثال ، بالنسبة للإجراءات المخزنة ، ستكون محتويات الملف هي التعريف الكامل للإجراء المخزن ، بدءًا من كتلة CREATE OR REPLACE FUNCTION .

كما يتضح من الجدول أعلاه ، يخزن مسار الملف معلومات حول نوع الكائن ونظامه واسمه. هذا الأسلوب يجعل من السهل التنقل خلال التغييرات مراجعة تفريغ الرمز إلى قاعدة البيانات.

يتم تحديد .sql للملفات ذات الكود المصدري للإجراءات المخزنة بحيث يوفر IDE تلقائيًا أدوات للتفاعل مع قاعدة البيانات عند فتح الملف.

كيفية تعقب التغييرات في بنية قاعدة البيانات بعد حفظ التفريغ

بعد حفظ تفريغ بنية قاعدة البيانات الحالية في VCS ، سنحصل على فرصة للتحقق مما إذا كانت التغييرات قد أجريت على بنية قاعدة البيانات بعد إنشاء التفريغ. توفر مكتبة حافظة المخطط وظيفة checkDump للكشف عن تغييرات هيكل قاعدة البيانات ، والتي تُرجع معلومات حول الاختلافات دون آثار جانبية.

طريقة بديلة للتحقق هي استدعاء وظيفة saveDump ، وتحديد نفس الدليل ، والتحقق من التغييرات في VCS. منذ أن يتم تخزين الكائنات من قاعدة البيانات في ملفات منفصلة ، فإن VCS سوف يعرض الكائنات التي تم تغييرها فقط. العيب الرئيسي لهذه الطريقة هو الحاجة إلى الكتابة فوق الملفات لرؤية التغييرات.

كيفية نقل التغييرات في بنية قاعدة البيانات إلى بيئات أخرى دون تعارضات وملفات الترحيل العملاقة

بفضل وظيفة publishDump ، يتم تحرير التعليمات البرمجية المصدر للإجراءات المخزنة تمامًا مثل باقي التعليمات البرمجية المصدر للتطبيق. يحدث تعديل الإجراء المخزن عن طريق إجراء تغييرات على الملف المقابل ، والذي ينعكس تلقائيًا في نظام التحكم في الإصدار.

على سبيل المثال ، لإنشاء إجراء مخزن جديد في المخطط public ، يكفي إنشاء ملف جديد بامتداد .sql في دليل public/functions deployDump ، ووضع الكود المصدري للإجراء المخزن فيه ، بما في ذلك كتلة CREATE OR REPLACE FUNCTION ، ثم استدعاء دالة deployDump . وبالمثل ، يتم تعديل الإجراء المخزن وحذفه. وبالتالي ، يدخل الكود في نفس الوقت في VCS وقاعدة البيانات.

إذا ظهر خطأ في الكود المصدري للإجراء المخزن ، فسوف تفشل عملية deployDump ، مما يؤدي إلى استثناء. عدم تطابق الإجراءات المخزنة بين التفريغ وقاعدة البيانات الحالية غير ممكن باستخدام deployDump .

عند إنشاء إجراء مخزن جديد ، ليست هناك حاجة لإدخال اسم الملف الصحيح يدويًا. يكفي أن الملف له الملحق .sql . يمكن الحصول على الاسم الصحيح من القيمة deployDump للدالة deployDump ، واستخدامها لإعادة تسمية الملف.

يغير deployDump معلمات الوظيفة أو نوع الإرجاع دون إجراءات إضافية ، بينما في النهج التقليدي سيكون من الضروري تنفيذ DROP FUNCTION ، وعندها فقط يتم CREATE OR REPLACE FUNCTION .

لسوء الحظ ، في بعض الحالات ، يفشل deployDump إلى تطبيق التغييرات تلقائيًا. على سبيل المثال ، إذا تم حذف وظيفة المشغل التي يستخدمها مشغل واحد على الأقل. يتم حل هذه الحالات يدويًا باستخدام ملفات الترحيل.

إذا كان مخطط المخطط مسؤولاً عن نقل التغييرات في الإجراءات المخزنة ، فسيتم استخدام ملفات الترحيل لنقل التغييرات الأخرى في البنية. على سبيل المثال ، مكتبة العقيدة / الهجرة مناسبة.

يجب تطبيق عمليات الترحيل قبل تشغيل deployDump أجل إجراء تغييرات على البنية وحل مواقف المشاكل المحتملة.

سيتم وصف العمل مع الهجرات بمزيد من التفصيل في الأقسام التالية.

كيفية تأسيس عملية عمل متوازي على مشروع من قبل العديد من المطورين

لنقم بإنشاء برنامج نصي لتهيئة قاعدة البيانات بالكامل ، والتي يعمل مطورو البرامج على الأجهزة المحلية لجعل بنية قواعد البيانات المحلية متوافقة مع التفريغ المخزن في VCS. نقسم التهيئة لقاعدة البيانات المحلية إلى 3 خطوات:

1. قم باستيراد ملف بهيكل أساسي ، والذي سيتم استدعاؤه ، على سبيل المثال ، base.sql
2. تطبيق الهجرات
3. استدعاء deployDump

base.sql هي نقطة البداية التي يتم فيها تطبيق عمليات الترحيل وتنفيذ عملية deployDump ، أي ، base.sql + + deployDump = . base.sql حصريًا عند تهيئة قاعدة البيانات من البداية. يتم إنشاء مثل هذا الملف باستخدام pg_dump .

نحن نسمي البرنامج النصي refresh.sh قاعدة بيانات كاملة refresh.sh . سير عمل المطور كما يلي:

1. تشغيل refresh.sh في بيئتك للحصول على بنية قاعدة البيانات الحالية
2. بداية العمل على المهمة ، تعديل قاعدة البيانات المحلية لاحتياجات الوظيفة الجديدة ( ALTER TABLE ... ADD COLUMN ، إلخ.)
3. بعد الانتهاء من المهمة ، اتصل بوظيفة saveDump لتنفيذ التغييرات التي تم إجراؤها على قاعدة البيانات في VCS
4. refresh.sh ثم verifyDump لعرض قائمة بالتغييرات التي سيتم تضمينها في الترحيل
5. نقل تغييرات الهيكل إلى ملف الترحيل ، وتشغيل refresh.sh verifyDump ، وإذا تم verifyDump الترحيل بشكل صحيح ، verifyDump أنه لا توجد فروق بين قاعدة البيانات المحلية وتفريغ المحفوظة

العملية المذكورة أعلاه متوافقة مع مبادئ gitflow . يحتوي كل فرع في VCS على نسخته الخاصة من التفريغ ، وعندما يتم دمج الفروع ، يتم تفريغ الدمج. يتم تنفيذ عمليات الدمج دون اتخاذ إجراءات إضافية ، ولكن إذا تم إجراء تغييرات في الفروع ، على سبيل المثال ، في نفس الجدول ، فيمكن حدوث تعارض.

ضع في اعتبارك حالة تعارض باستخدام مثال فرع التطوير ، منها الفرع 1 والفرع 2 ، والذي لا يتعارض مع التطوير ، ولكن يتعارض مع بعضهما البعض. المهمة هي دمج branch1 و branch2 في التطوير. لمثل هذه الحالة ، يوصى أولاً بدمج branch1 في التطوير ، ثم دمج التطوير في branch2 ، وحل التعارضات في branch2 ، ثم دمج branch2 في التطوير. في مرحلة حل النزاع ، قد تضطر إلى إصلاح ملف الترحيل في branch2 بحيث يطابق التفريغ النهائي ، والذي يتضمن نتائج عمليات الدمج.

كيفية نشر المزيد من التغييرات بأمان إلى بنية قاعدة البيانات إلى بيئة الإنتاج

يتيح لك وجود بنية قاعدة البيانات الحالية في تفريغ VCS التحقق من قاعدة الإنتاج للتأكد من توافقها التام مع الهيكل المطلوب. هذا يضمن أن جميع التغييرات التي يقصدها المطورون تم نقلها إلى قاعدة الإنتاج.

نظرًا لأن DDL في PostgreSQL معاملات ، فمن المستحسن أن تتبع ترتيب النشر بحيث يكون ROLLBACK في حالة حدوث خطأ غير متوقع:

1. بدء المعاملة
2. نفذ جميع عمليات الترحيل في معاملة
3. في نفس المعاملة ، قم بتنفيذ deployDump
4. بدون إكمال المعاملة ، قم بتشغيل verifyDump . في حالة عدم وجود أخطاء ، قم بتنفيذ COMMIT . في حالة وجود أخطاء ، قم بتنفيذ ROLLBACK

من السهل دمج هذه الخطوات في الأساليب الحالية لنشر التطبيقات ، بما في ذلك التوقف عن العمل.

استنتاج

بفضل الطرق الموضحة أعلاه ، يمكنك الضغط على أقصى أداء من مشاريع "PHP + PostgreSQL" ، مع التضحية بقدر ضئيل نسبياً من الراحة في التطوير مقارنةً بتنفيذ كل منطق الأعمال في رمز التطبيق الرئيسي. علاوة على ذلك ، غالباً ما تبدو معالجة البيانات في PL / pgSQL أكثر شفافية وتتطلب كودًا أقل من نفس الوظيفة المكتوبة بلغة PHP.