هدف این مقاله استفاده از مثال کتابخانه است طرحواره نگهدار ابزارهایی را نشان می دهد که می توانند به طور قابل توجهی فرآیند توسعه پایگاه داده در پروژه های PHP را با استفاده از PostgreSQL DBMS ساده کنند.

اطلاعات این مقاله اول از همه برای توسعه دهندگانی مفید خواهد بود که می خواهند از قابلیت های PostgreSQL حداکثر استفاده را ببرند، اما با مشکلاتی در حفظ منطق تجاری قرار داده شده در پایگاه داده مواجه هستند.

در این مقاله مزایا یا معایب ذخیره منطق تجاری در پایگاه داده توضیح داده نمی شود. فرض بر این است که انتخاب قبلاً توسط خواننده انجام شده است.

سوالات زیر در نظر گرفته خواهد شد:

1. به چه شکلی باید یک Dump ساختار پایگاه داده در یک سیستم کنترل نسخه (که از این پس VCS نامیده می شود) ذخیره شود.
2. نحوه ردیابی تغییرات در ساختار پایگاه داده پس از ذخیره dump
3. نحوه انتقال تغییرات در ساختار پایگاه داده به محیط های دیگر بدون درگیری و فایل های مهاجرت غول پیکر
4. نحوه سازماندهی فرآیند کار موازی روی یک پروژه توسط چندین توسعه دهنده
5. نحوه اجرای ایمن تغییرات بیشتر در ساختار پایگاه داده در یک محیط تولید
   

   SchemaKeeper طراحی شده برای کار با رویه های ذخیره شده نوشته شده به زبان PL/pgSQL. آزمایش با زبان های دیگر انجام نشده است، بنابراین استفاده ممکن است به همان اندازه موثر نباشد یا ممکن نباشد.

نحوه ذخیره یک Dump ساختار پایگاه داده در VCS

کتابخانه طرحواره نگهدار یک تابع ارائه می دهد saveDump، که ساختار تمام اشیاء را از پایگاه داده به عنوان فایل متنی جداگانه ذخیره می کند. خروجی یک دایرکتوری حاوی ساختار پایگاه داده است که به فایل های گروه بندی شده تقسیم شده است که به راحتی می توان به VCS اضافه کرد.

بیایید با استفاده از چندین مثال به تبدیل اشیا از پایگاه داده به فایل ها نگاه کنیم:

نوع شی
طرح
نام
مسیر نسبی به فایل

جدول
عمومی
حساب
./public/tables/accounts.txt

رویه ذخیره شده
عمومی
auth (هش بیگینت)
./public/functions/auth(int8).sql

مقدمه
رزرو
تعرفه ها
./booking/views/tariffs.txt

محتویات فایل ها نمایش متنی ساختار یک شی پایگاه داده خاص است. به عنوان مثال، برای رویه های ذخیره شده، محتویات فایل، تعریف کامل رویه ذخیره شده خواهد بود که با بلوک شروع می شود. CREATE OR REPLACE FUNCTION.

همانطور که از جدول بالا مشاهده می شود، مسیر فایل اطلاعاتی در مورد نوع، طرح و نام شیء ذخیره می کند. این رویکرد، پیمایش را از طریق بازبینی و بررسی کد تغییرات در پایگاه داده آسان‌تر می‌کند.

گسترش .sql برای فایل‌های دارای کد منبع رویه ذخیره‌شده، این به گونه‌ای انتخاب شد که IDE به‌طور خودکار ابزارهایی را برای تعامل با پایگاه داده در هنگام باز شدن فایل فراهم می‌کند.

نحوه ردیابی تغییرات در ساختار پایگاه داده پس از ذخیره dump

با ذخیره یک Dump از ساختار پایگاه داده فعلی در VCS، این فرصت را به دست می آوریم تا بررسی کنیم که آیا تغییراتی در ساختار پایگاه داده پس از ایجاد dump ایجاد شده است یا خیر. در کتابخانه طرحواره نگهدار برای تشخیص تغییرات در ساختار پایگاه داده، یک تابع ارائه شده است verifyDump، که اطلاعات مربوط به تفاوت ها را بدون عوارض جانبی برمی گرداند.

یک راه جایگزین برای بررسی، فراخوانی مجدد تابع است saveDump، همان دایرکتوری را مشخص کنید و VCS را برای تغییرات بررسی کنید. از آنجایی که تمام اشیاء از پایگاه داده در فایل های جداگانه ذخیره می شوند، VCS فقط اشیاء تغییر یافته را نشان می دهد.
عیب اصلی این روش نیاز به بازنویسی فایل ها برای مشاهده تغییرات است.

نحوه انتقال تغییرات در ساختار پایگاه داده به محیط های دیگر بدون درگیری و فایل های مهاجرت غول پیکر

با تشکر از عملکرد deployDump کد منبع رویه های ذخیره شده را می توان دقیقاً به همان روشی که کد منبع برنامه معمولی ویرایش کرد. می توانید خطوط جدیدی را در کد رویه ذخیره شده اضافه یا حذف کنید و بلافاصله تغییرات را به کنترل نسخه فشار دهید، یا با ایجاد/حذف فایل های مربوطه در فهرست dump، رویه های ذخیره شده را ایجاد/حذف کنید.

به عنوان مثال، برای ایجاد یک رویه ذخیره شده جدید در یک طرحواره public فقط یک فایل جدید با پسوند ایجاد کنید .sql در دایرکتوری public/functions، کد منبع رویه ذخیره شده، از جمله بلوک را در آن قرار دهید CREATE OR REPLACE FUNCTION، سپس تابع را فراخوانی کنید deployDump. اصلاح و حذف یک رویه ذخیره شده به همین ترتیب انجام می شود. بنابراین، کد به طور همزمان به VCS و پایگاه داده می رود.

اگر خطایی در کد منبع هر رویه ذخیره شده ظاهر شود یا بین نام فایل و رویه ذخیره شده مغایرت وجود داشته باشد، سپس deployDump شکست خواهد خورد، متن خطا نمایش داده می شود. عدم تطابق رویه های ذخیره شده بین dump و پایگاه داده فعلی در هنگام استفاده غیرممکن است deployDump.

هنگام ایجاد یک رویه ذخیره شده جدید، نیازی به وارد کردن دستی نام فایل صحیح نیست. کافی است فایل پسوند داشته باشد .sql. بعد از تماس deployDump متن خطا حاوی نام صحیحی است که می توان از آن برای تغییر نام فایل استفاده کرد.

deployDump به شما امکان می دهد پارامترهای یک تابع یا نوع برگرداندن را بدون اقدامات اضافی تغییر دهید، در حالی که با رویکرد کلاسیک باید
ابتدا اجرا کنید DROP FUNCTION، و فقط پس از آن CREATE OR REPLACE FUNCTION.

متأسفانه، شرایطی وجود دارد که در آن deployDump قادر به اعمال خودکار تغییرات نیست. به عنوان مثال، اگر یک تابع ماشه ای که حداقل توسط یک ماشه استفاده می شود حذف شود. چنین موقعیت هایی با استفاده از فایل های مهاجرت به صورت دستی حل می شوند.

اگر شما مسئول انتقال تغییرات به رویه های ذخیره شده هستید طرحواره نگهدار، سپس فایل های مهاجرت باید برای انتقال سایر تغییرات در ساختار استفاده شود. به عنوان مثال، یک کتابخانه خوب برای کار با مهاجرت است دکترین/مهاجرت ها.

مهاجرت ها باید قبل از راه اندازی اعمال شوند deployDump. این به شما امکان می دهد تا تمام تغییرات را در ساختار ایجاد کنید و موقعیت های مشکل ساز را حل کنید تا تغییرات در رویه های ذخیره شده متعاقباً بدون مشکل منتقل شوند.

کار با مهاجرت با جزئیات بیشتر در بخش های بعدی توضیح داده خواهد شد.

نحوه سازماندهی فرآیند کار موازی روی یک پروژه توسط چندین توسعه دهنده

لازم است یک اسکریپت برای اولیه سازی کامل پایگاه داده ایجاد شود که توسط توسعه دهنده بر روی ماشین کاری خود راه اندازی می شود و ساختار پایگاه داده محلی را مطابق با dump ذخیره شده در 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 هیچ تفاوتی بین پایگاه داده محلی و dump ذخیره شده نشان نخواهد داد

فرآیندی که در بالا توضیح داده شد با اصول gitflow سازگار است. هر شعبه در VCS شامل نسخه خود از dump است و هنگام ادغام شاخه ها، dump ها ادغام می شوند. در بیشتر موارد، پس از ادغام، نیازی به انجام هیچ اقدام اضافی نیست، اما اگر تغییراتی در شاخه های مختلف، به عنوان مثال، در یک جدول انجام شود، ممکن است تضاد ایجاد شود.

بیایید یک موقعیت درگیری را با استفاده از یک مثال در نظر بگیریم: یک شاخه وجود دارد توسعه، که از آن دو شاخه منشعب می شود: ویژگی1 и ویژگی2، که هیچ تضادی با آنها ندارند توسعه، اما با یکدیگر درگیری دارند. وظیفه ادغام هر دو شاخه است توسعه. برای این مورد، توصیه می شود ابتدا یکی از شاخه ها را ادغام کنید توسعهو سپس ادغام شوند توسعه به شاخه باقیمانده، حل تعارضات در شاخه باقی مانده، و سپس ادغام آخرین شاخه در توسعه. در مرحله حل تضاد، ممکن است مجبور شوید فایل مهاجرت را در آخرین شاخه اصلاح کنید تا با dump نهایی مطابقت داشته باشد، که شامل نتایج ادغام ها می شود.

نحوه اجرای ایمن تغییرات بیشتر در ساختار پایگاه داده در یک محیط تولید

به لطف وجود یک dump از ساختار پایگاه داده فعلی در VCS، بررسی پایگاه داده تولید برای مطابقت دقیق با ساختار مورد نیاز امکان پذیر می شود. این تضمین می کند که تمام تغییرات مورد نظر توسعه دهندگان با موفقیت به پایگاه تولید منتقل شده است.

مانند DDL در PostgreSQL است معاملاتی، توصیه می شود به ترتیب استقرار زیر پایبند باشید تا در صورت بروز خطای غیرمنتظره، بتوانید بدون دردسر اجرا کنید ROLLBACK:

1. شروع معامله
2. تمام انتقال ها را در یک تراکنش انجام دهید
3. در همان تراکنش، اجرا کنید deployDump
4. بدون تکمیل تراکنش، اجرا کنید verifyDump. اگر خطایی وجود ندارد، اجرا کنید COMMIT. اگر خطا وجود دارد، اجرا کنید ROLLBACK

این مراحل را می توان به راحتی در رویکردهای موجود برای استقرار برنامه، از جمله زمان توقف صفر، ادغام کرد.

نتیجه

به لطف روش‌هایی که در بالا توضیح داده شد، می‌توان حداکثر کارایی را از پروژه‌های "PHP + PostgreSQL" کم کرد، در حالی که راحتی توسعه نسبتاً کمی را در مقایسه با پیاده‌سازی تمام منطق تجاری در کد برنامه اصلی قربانی کرد. علاوه بر این، پردازش داده ها در PL/pgSQL اغلب شفاف‌تر به نظر می‌رسد و نیاز به کد کمتری نسبت به عملکرد مشابهی دارد که در PHP نوشته شده است.

منبع: www.habr.com