ڈیٹابیس کیا ہے؟ ایپ بنانے والوں کے لیے رہنما

ڈیٹابیس معلومات کا منظم ذخیرہ ہے جس میں ایپ اپنے صارفین، آرڈرز، بکنگز اور پیغامات محفوظ کرتی اور پڑھتی ہے۔ براؤزر ٹیب میں رکھی گئی معلومات کے برعکس، ڈیٹابیس کا ڈیٹا ریفریش یا ری اسٹارٹ کے بعد بھی موجود رہتا ہے، اور ایپ استعمال کرنے والا ہر شخص ایک ہی ریکارڈ دیکھتا ہے۔ زیادہ تر ڈیٹابیسز ڈیٹا کو ٹیبلز میں رکھتے ہیں، جو اسپریڈشیٹ کی شیٹس جیسی ہوتی ہیں، لیکن سخت اصولوں کے ساتھ جو ڈیٹا کو مستقل رکھتے ہیں۔

AI کے ساتھ تعمیر کرتے وقت یہ کیوں اہم ہے

AI کے ساتھ کچھ بنانے والوں کے لیے سب سے عام حیرانی یہ ہوتی ہے کہ ایپ مکمل نظر آتی ہے مگر سب کچھ بھول جاتی ہے۔ آپ ایک گاہک شامل کرتے ہیں، صفحہ ریفریش کرتے ہیں، اور وہ غائب ہو جاتا ہے۔ اس کا عموماً مطلب ہے کہ ایپ ڈیٹا ڈیٹابیس کے بجائے براؤزر کی میموری میں رکھ رہی تھی۔

ڈیٹابیس وہ جگہ بھی ہے جہاں آپ کے کئی اہم فیصلے رہتے ہیں، چاہے آپ اسے سمجھیں یا نہ سمجھیں:

• آپ کیا ریکارڈ کرتے ہیں۔ اگر آپ بکنگ کا اسٹیٹس محفوظ نہیں کرتے، تو آپ یہ نہیں دکھا سکتے کہ کون سی بکنگز منسوخ ہوئیں۔
• چیزیں آپس میں کیسے جڑتی ہیں۔ کیا ایک گاہک کی کئی بکنگز ہو سکتی ہیں، یا ایک بکنگ کی کئی سروسز، یہ پوری ایپ کی شکل طے کرتا ہے۔
• کون کیا دیکھ سکتا ہے۔ زیادہ تر رازداری کی غلطیاں اس بارے میں ہوتی ہیں کہ صارف کون سے ریکارڈ پڑھ سکتا ہے۔

آپ کو ڈیٹابیس خود ڈیزائن کرنے کی ضرورت نہیں۔ لیکن بنیادی باتیں سمجھنے سے آپ اپنا ڈیٹا واضح طور پر بیان کر سکتے ہیں اور مسائل جلد پکڑ سکتے ہیں۔

روزمرہ کی مثال

ایک چھوٹے دفتر کی منظم فائلنگ کیبنٹ کا تصور کریں۔

ہر دراز میں ایک ہی قسم کی چیز ہوتی ہے: ایک دراز گاہکوں کے لیے، ایک ملاقاتوں کے لیے، ایک انوائسز کے لیے۔ ہر دراز کے اندر ہر فولڈر ایک ہی شکل کا ہوتا ہے، جس میں ایک جیسے خانے بھرے ہوتے ہیں۔ ہر فولڈر کا ایک منفرد حوالہ نمبر ہوتا ہے، اور جب کوئی انوائس کسی گاہک کی ہو، تو انوائس کا فولڈر اس گاہک کا نمبر لکھ دیتا ہے، پوری فائل کی نقل نہیں بناتا۔

یہ ایک ریلیشنل ڈیٹابیس ہے۔ دراز ٹیبلز ہیں، فولڈر قطاریں (rows) ہیں، خانے کالم ہیں، حوالہ نمبر primary keys ہیں، اور دوسرے فولڈر کی طرف اشارہ کرنے والے نوٹس foreign keys ہیں۔ ایک اچھا دفتری منیجر اصول بھی لاگو کرتا ہے، جیسے بغیر تاریخ کے ملاقات نہیں، اور ایک ہی نمبر والے دو گاہک نہیں، بالکل ویسے ہی جیسے ڈیٹابیس کرتا ہے۔

ایک عملی مثال: سیلون بکنگ ایپ

فرض کریں آپ AI سے ہیئر سیلون کے لیے بکنگ سائٹ بنواتے ہیں۔ ایک معقول ڈیٹابیس میں چار ٹیبلز ہوں گی۔

services

staff

customers

bookings

bookings ٹیبل کو دیکھیں۔ یہ ہر بکنگ میں Lena کا نام اور فون نمبر نہیں نقل کرتی؛ یہ customer_id = 101 محفوظ کرتی ہے۔ اگر Lena اپنا فون نمبر بدلے، تو وہ ایک ہی جگہ بدلتا ہے اور ہر بکنگ نیا نمبر دکھاتی ہے۔ یہی ریلیشنل ڈیٹابیس کا بنیادی خیال ہے: ہر حقیقت ایک بار محفوظ کریں، اور اس سے جوڑیں۔

یہی ڈھانچہ مفید سوالات کے جواب بھی دیتا ہے:

• “جمعہ کو Omar کے کون سے سلاٹس خالی ہیں؟” — اس دن Omar کی بکنگز دیکھیں۔
• “اس مہینے Colour سروسز نے کتنی کمائی کی؟” — bookings کو services سے جوڑیں اور قیمتیں جمع کریں۔
• “کون سے گاہک 90 دن سے نہیں آئے؟” — گاہکوں کا تازہ ترین بکنگ سے موازنہ کریں۔

عام اصطلاحات کی وضاحت

ڈیٹابیسز کی اقسام

کسی کاروباری شخص یا چھوٹے کاروبار کی پہلی بنائی گئی تقریباً ہر چیز کے لیے ریلیشنل ڈیٹابیس محفوظ ڈیفالٹ ہے۔

ڈیٹابیس آپ کی ایپ میں کہاں ہے

وزیٹرز ڈیٹابیس سے براہِ راست بات نہیں کرتے۔ ان کے براؤزر کا صفحہ (فرنٹ اینڈ) عموماً API کے ذریعے آپ کے سرور (بیک اینڈ) سے ڈیٹا مانگتا ہے۔ سرور جانچتا ہے کہ پوچھنے والا کون ہے اور کیا اسے اجازت ہے، پھر ڈیٹابیس سے کوئری کرتا ہے اور صرف وہی ڈیٹا واپس بھیجتا ہے جو اس شخص کو دیکھنا چاہیے۔

یہ درمیانی قدم اہم ہے۔ اگر براؤزر مکمل رسائی کے ساتھ ڈیٹابیس سے براہِ راست کوئری کر سکتا، تو کوئی بھی ڈیولپر ٹولز کھول کر سب کچھ پڑھ سکتا۔

عام غلطیاں اور غلط فہمیاں

• ڈیٹا صرف براؤزر میں رکھنا۔ براؤزر اسٹوریج (جیسے localStorage) ایک آلے اور ایک براؤزر پر رہتا ہے۔ کسی یاد رکھے گئے فلٹر کے لیے ٹھیک ہے، آرڈرز کے لیے نہیں۔
• سب کچھ ایک ٹیبل میں ٹھونس دینا۔ ایک “bookings” ٹیبل جس کی ہر قطار میں گاہک کا نام، فون اور سروس کی قیمت نقل ہو، جلد ہی بے ترتیب ہو جاتی ہے۔
• پاس ورڈ سادہ متن میں محفوظ کرنا۔ پاس ورڈز ہیش ہونے چاہئیں، کبھی پڑھے جانے کے قابل نہیں۔ دیکھیں authentication کیا ہے۔
• ڈیٹا پر کوئی اصول نہ ہونا۔ لازمی فیلڈز اور منفرد ہونے کے اصولوں کے بغیر بغیر تاریخ کی بکنگز اور ڈپلیکیٹ گاہک آ جائیں گے۔
• حذف کرنا بھول جانا۔ طے کریں کہ گاہک حذف کرنے سے اس کی بکنگز حذف ہوں گی، محفوظ رہیں گی، یا روک دی جائیں گی۔
• تجربات کے لیے پروڈکشن ڈیٹا استعمال کرنا۔ خطرناک تبدیلیاں پہلے کہیں محفوظ جگہ پر آزمائیں، اور بیک اپ رکھیں۔
• اسپریڈشیٹ کو ہمیشہ کے لیے ڈیٹابیس سمجھنا۔ اسپریڈشیٹ شروعات کے لیے بہترین ہیں، لیکن بہت سے بیک وقت صارفین اور اجازتوں میں مشکل آتی ہے۔ دیکھیں اسپریڈشیٹ کو ایپ میں کیسے بدلیں۔

AI بلڈر سے کیا مانگیں

• “اسے براؤزر میں نہیں، ڈیٹابیس میں محفوظ کریں۔ بتائیں کہ آپ کون سی ٹیبلز بنائیں گے۔”
• “schema کو سادہ ٹیبل کی شکل میں دکھائیں: ہر ٹیبل، اس کے کالم اور وہ کیسے جڑتی ہیں۔”
• “ایک گاہک کی کئی بکنگز ہو سکتی ہیں؛ ہر بکنگ کی ایک سروس اور ایک اسٹاف ممبر ہوگا۔”
• “گاہکوں کے لیے ای میل لازمی اور منفرد بنائیں۔”
• “ایک ہی اسٹاف ممبر کی دو بکنگز آپس میں اوورلیپ نہ ہونے دیں۔”
• “صرف لاگ ان مالک تمام بکنگز دیکھ سکے؛ گاہک صرف اپنی بکنگز دیکھ سکیں۔ یہ سرور پر نافذ کریں۔”
• “جب میں کوئی سروس حذف کروں تو پچھلی بکنگز حذف نہ کریں، بلکہ سروس کو غیر فعال نشان زد کریں۔”

Mythex میں ڈیٹابیسز

جب آپ کی ایپ کو ڈیٹا محفوظ کرنا ہو، تو Mythex پروجیکٹ میں ایک مخصوص Postgres ڈیٹابیس شامل کرتا ہے۔ آپ چیٹ میں پوچھ سکتے ہیں (“ویٹ لسٹ سائن اپس ڈیٹابیس میں محفوظ کرو”) یا /database کمانڈ استعمال کر سکتے ہیں۔ کنکشن کی تفصیلات خود بخود آپ کی ایپ کو دی جاتی ہیں، اور ایجنٹ ٹیبلز بناتا ہے۔ ڈیٹابیس پانچ منٹ کی بے کاری کے بعد سو جاتا ہے اور اگلی درخواست پر جاگ جاتا ہے، اور شائع شدہ استعمال کا بل اس وقت کا لگتا ہے جب وہ جاگتا رہا، اسی کریڈٹ بیلنس سے جو تعمیر کے لیے استعمال ہوتا ہے۔ یہ Free اور Pro دونوں پر دستیاب ہے۔ تفصیلات کے لیے ڈیٹابیس دستاویزات دیکھیں، اور ایپ ٹیمپلیٹس میں ڈیٹا پر مبنی ابتدائی نقطے ملیں گے۔

سوالات