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

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

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

سيتم النظر في الأسئلة التالية:

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

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

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

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

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

نوع الكائن
القيادة
الاسم
المسار النسبي للملف

طاولة
جمهور
حسابات
./public/tables/accounts.txt

الإجراء المخزن
جمهور
المصادقة (التجزئة الكبيرة)
./public/functions/auth(int8).sql

فكرة
حجز
التعريفات
./booking/views/tariffs.txt

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

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

تمديد .sql بالنسبة للملفات ذات التعليمات البرمجية المصدرية للإجراء المخزن، تم تحديد هذا بحيث يوفر 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 غير قادر على تطبيق التغييرات تلقائيا. على سبيل المثال، إذا تمت إزالة وظيفة المشغل التي يستخدمها مشغل واحد على الأقل. يتم حل مثل هذه المواقف يدويًا باستخدام ملفات الترحيل.

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

يجب تطبيق عمليات الترحيل قبل الإطلاق 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 على نسخته الخاصة من التفريغ، وعند دمج الفروع، سيتم دمج التفريغات. في معظم الحالات، لا يلزم اتخاذ أي إجراء إضافي بعد الدمج، ولكن إذا تم إجراء تغييرات في فروع مختلفة، على سبيل المثال، على نفس الجدول، فقد ينشأ تعارض.

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

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

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

كما DDL في PostgreSQL هو المعاملات، يوصى بالالتزام بأمر النشر التالي، بحيث يمكنك التنفيذ "بسهولة" في حالة حدوث خطأ غير متوقع ROLLBACK:

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

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

اختتام

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

المصدر: www.habr.com