اس مضمون کا مقصد لائبریری کی مثال استعمال کرنا ہے۔ سکیما کیپر ایسے ٹولز دکھائیں جو PostgreSQL DBMS کا استعمال کرتے ہوئے PHP پروجیکٹس کے اندر ڈیٹا بیس تیار کرنے کے عمل کو نمایاں طور پر آسان بنا سکتے ہیں۔

اس مضمون کی معلومات، سب سے پہلے، ان ڈویلپرز کے لیے کارآمد ہوں گی جو PostgreSQL کی صلاحیتوں سے زیادہ سے زیادہ فائدہ اٹھانا چاہتے ہیں، لیکن ڈیٹا بیس میں رکھی گئی کاروباری منطق کو برقرار رکھنے میں مسائل کا سامنا ہے۔

یہ مضمون کاروباری منطق کو ڈیٹا بیس میں ذخیرہ کرنے کے فوائد یا نقصانات کو بیان نہیں کرے گا۔ یہ فرض کیا جاتا ہے کہ انتخاب قاری پہلے ہی کر چکا ہے۔

درج ذیل سوالات پر غور کیا جائے گا:

1. ڈیٹا بیس ڈھانچہ ڈمپ کو ورژن کنٹرول سسٹم میں کس شکل میں ذخیرہ کیا جانا چاہئے (اس کے بعد VCS کہا جاتا ہے)
2. ڈمپ کو بچانے کے بعد ڈیٹا بیس کے ڈھانچے میں ہونے والی تبدیلیوں کو کیسے ٹریک کیا جائے۔
3. ڈیٹا بیس کے ڈھانچے میں ہونے والی تبدیلیوں کو بغیر تنازعات اور بڑی منتقلی فائلوں کے دوسرے ماحول میں کیسے منتقل کیا جائے۔
4. متعدد ڈویلپرز کے ذریعہ کسی پروجیکٹ پر متوازی کام کے عمل کو کیسے منظم کریں۔
5. ڈیٹا بیس کے ڈھانچے میں مزید تبدیلیوں کو پروڈکشن ماحول میں محفوظ طریقے سے کیسے تعینات کیا جائے۔
   

   سکیم کیپر زبان میں لکھے گئے ذخیرہ شدہ طریقہ کار کے ساتھ کام کرنے کے لیے ڈیزائن کیا گیا ہے۔ PL / pgSQL. دوسری زبانوں کے ساتھ جانچ نہیں کی گئی ہے، لہذا استعمال اتنا مؤثر نہیں ہوسکتا ہے یا ممکن نہیں ہے۔

VCS میں ڈیٹا بیس سٹرکچر ڈمپ کو کیسے اسٹور کیا جائے۔

لائبریری سکیما کیپر ایک فنکشن فراہم کرتا ہے۔ saveDump، جو ڈیٹا بیس سے تمام اشیاء کی ساخت کو علیحدہ ٹیکسٹ فائلوں کے طور پر محفوظ کرتا ہے۔ آؤٹ پٹ ایک ڈائرکٹری ہے جس میں ڈیٹابیس کی ساخت ہوتی ہے، جسے گروپ شدہ فائلوں میں تقسیم کیا جاتا ہے جنہیں آسانی سے VCS میں شامل کیا جا سکتا ہے۔

آئیے کئی مثالوں کا استعمال کرتے ہوئے ڈیٹا بیس سے اشیاء کو فائلوں میں تبدیل کرتے ہوئے دیکھتے ہیں۔

объекта объекта
ڈرائیونگ
نام
فائل کا رشتہ دار راستہ

ٹیبل
عوامی
اکاؤنٹس
./public/tables/accounts.txt

ذخیرہ شدہ طریقہ کار
عوامی
auth (ہیش بگنٹ)
./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. کام مکمل کرنے کے بعد، ڈویلپر فنکشن کو کال کرتا ہے۔ saveDumpVCS میں ڈیٹا بیس میں کی گئی تبدیلیوں کا ارتکاب کرنا
4. ڈیولپر دوبارہ لانچ کریں۔ refresh.shپھر verifyDumpجو اب منتقلی میں شامل کرنے کے لیے تبدیلیوں کی فہرست دکھاتا ہے۔
5. ڈویلپر تمام ساختی تبدیلیاں منتقلی فائل میں منتقل کرتا ہے، دوبارہ چلتا ہے۔ refresh.sh и verifyDump، اور، اگر ہجرت کو صحیح طریقے سے مرتب کیا گیا ہے، verifyDump مقامی ڈیٹا بیس اور محفوظ شدہ ڈمپ کے درمیان کوئی فرق نہیں دکھائے گا۔

اوپر بیان کردہ عمل گٹ فلو اصولوں کے ساتھ مطابقت رکھتا ہے۔ VCS میں ہر شاخ میں ڈمپ کا اپنا ورژن ہوگا، اور شاخوں کو ضم کرنے پر، ڈمپ کو ضم کردیا جائے گا۔ زیادہ تر معاملات میں، انضمام کے بعد کوئی اضافی کارروائی کرنے کی ضرورت نہیں ہے، لیکن اگر تبدیلیاں مختلف شاخوں میں کی گئی ہیں، مثال کے طور پر، ایک ہی میز پر، تو تنازعہ پیدا ہو سکتا ہے۔

آئیے ایک مثال کا استعمال کرتے ہوئے تنازعہ کی صورتحال پر غور کریں: ایک شاخ ہے۔ ترقی، جس سے دو شاخیں شاخیں: فیچر ایکس این ایم ایکس ایکس۔ и فیچر ایکس این ایم ایکس ایکس۔جس کے ساتھ کوئی تضاد نہیں ہے۔ ترقی، لیکن ایک دوسرے کے ساتھ تنازعات ہیں۔ کام دونوں شاخوں کو ضم کرنا ہے۔ ترقی. اس صورت میں، یہ سب سے پہلے شاخوں میں سے ایک میں ضم کرنے کی سفارش کی جاتی ہے ترقیاور پھر ضم کریں ترقی بقیہ برانچ میں، بقیہ برانچ میں تنازعات کو حل کرنا، اور پھر آخری برانچ کو اس میں ضم کرنا ترقی. تنازعات کے حل کے مرحلے کے دوران، آپ کو آخری برانچ میں منتقلی کی فائل کو ٹھیک کرنا پڑ سکتا ہے تاکہ یہ حتمی ڈمپ سے مماثل ہو، جس میں انضمام کے نتائج شامل ہیں۔

ڈیٹا بیس کے ڈھانچے میں مزید تبدیلیوں کو پروڈکشن ماحول میں محفوظ طریقے سے کیسے تعینات کیا جائے۔

VCS میں موجودہ ڈیٹا بیس کے ڈھانچے کے ڈمپ کی موجودگی کی بدولت، مطلوبہ ڈھانچے کے عین مطابق تعمیل کے لیے پروڈکشن ڈیٹا بیس کو چیک کرنا ممکن ہو جاتا ہے۔ یہ اس بات کو یقینی بناتا ہے کہ وہ تمام تبدیلیاں جن کا ڈویلپرز کا ارادہ تھا کامیابی کے ساتھ پروڈکشن بیس میں منتقل کر دیا گیا تھا۔

جیسا کہ DDL PostgreSQL میں ہے۔ لین دین، مندرجہ ذیل تعیناتی آرڈر پر عمل کرنے کی سفارش کی جاتی ہے، تاکہ، کسی غیر متوقع غلطی کی صورت میں، آپ "بے دردی سے" عملدرآمد کر سکیں ROLLBACK:

1. لین دین شروع کریں۔
2. لین دین میں تمام منتقلی کو انجام دیں۔
3. ایک ہی لین دین میں، عملدرآمد deployDump
4. لین دین کو مکمل کیے بغیر عمل کریں۔ verifyDump. اگر کوئی غلطیاں نہیں ہیں تو چلائیں۔ COMMIT. اگر غلطیاں ہیں تو چلائیں۔ ROLLBACK

ان اقدامات کو آسانی سے ایپلیکیشن کی تعیناتی کے موجودہ طریقوں میں ضم کیا جا سکتا ہے، بشمول صفر ڈاؤن ٹائم۔

حاصل يہ ہوا

اوپر بیان کردہ طریقوں کی بدولت، "PHP + PostgreSQL" پروجیکٹس میں سے زیادہ سے زیادہ کارکردگی کو نچوڑنا ممکن ہے، جبکہ مین ایپلیکیشن کوڈ میں تمام کاروباری منطق کو لاگو کرنے کے مقابلے میں نسبتاً کم ترقی کی سہولت کو قربان کرنا ممکن ہے۔ مزید یہ کہ ڈیٹا پروسیسنگ میں PL / pgSQL اکثر زیادہ شفاف نظر آتا ہے اور پی ایچ پی میں لکھی گئی اسی فعالیت سے کم کوڈ کی ضرورت ہوتی ہے۔

ماخذ: www.habr.com