فائر اسٹور ڈیٹا ماڈلنگ گائیڈ: ایمبیڈڈ دستاویزات اور حوالہ جات (بشمول بلاگ کیس اسٹڈیز)

جب ڈویلپرز رشتہ دار دنیا (MySQL, PostgreSQL) سے Firestore، Firebase کے NoSQL دستاویز کے ڈیٹا بیس میں منتقل ہوتے ہیں، تو وہ اکثر اپنے ساتھ پرانی عادتیں لاتے ہیں۔ آپ میزیں، غیر ملکی چابیاں، اور جوائنز کو نقل کرنا چاہتے ہیں۔

نتائج کیا ہیں؟ پیچیدہ سوالات، پڑھے جانے والے اخراجات، اور ڈیٹا بیس کا ڈھانچہ جو صرف چند خصوصیات کے ساتھ برقرار رکھنا ایک ڈراؤنا خواب بن جاتا ہے۔

یہ سمجھنے کے لیے کہ Firestore کیسے کام کرتا ہے، ہمیں پہلے موازنہ کے نقطہ کے طور پر اس کے متعلقہ ماڈل کو دیکھنے کی ضرورت ہے۔ یہ سمجھنا کہ SQL کیسے کام کرتا ہے آپ کو یہ دیکھنے کی اجازت دیتا ہے کہ Firestore کی شاخیں کہاں سے نکلتی ہیں اور NoSQL ڈیٹا کو صحیح طریقے سے کیسے ڈھانچا جاتا ہے۔

یہ گائیڈ NoSQL ڈیزائن کے اصولوں، سرایت کرنے اور حوالہ جات، اور متعلقہ ماڈلنگ (1-1، 1-N، NN) کا احاطہ کرتا ہے۔ ہم ایک مخصوص بلاگ کیس اسٹڈی کو بھی دیکھیں گے۔

انڈیکس

شرائط
متعلقہ سوچ: ایس کیو ایل ڈیٹا پر کیسے عمل کرتا ہے۔
فائر اسٹور کا نمونہ: رشتہ دار NoSQL
بنیادی عمارت کے بلاکس: دستاویزات اور مجموعہ
سنہری اصول: پڑھنے کا ایک نمونہ، لکھنے کا نہیں۔
ایمبیڈنگز اور حوالہ جات (غیر نارملائزیشن)
رشتہ ماڈلنگ کے طریقے (1-1، 1-N، NN)
بہترین طریقوں اور نقصانات سے بچنے کے لیے
کیس اسٹڈی: توسیع پذیر بلاگ ڈیٹا بیس کو ڈیزائن کرنا

شرائط

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

تمام کوڈ کی مثالیں ماڈیولر Firebase JS SDK (v9+) کا استعمال کرتی ہیں، لہذا وہ مقامی JavaScript نحو ہیں۔
JSON آبجیکٹ کا بنیادی علم (کیز، ویلیوز، نیسٹڈ آبجیکٹ، ارے)
ایس کیو ایل یا متعلقہ ڈیٹا بیسز کی نمائش مددگار ہے (لیکن اس کی ضرورت نہیں)، کیونکہ گائیڈ ان موازنہوں پر بھروسہ کرتا ہے۔
(اختیاری) اگر آپ خود مثالیں آزمانا چاہتے ہیں، تو یہ ایک مفت Firebase پروجیکٹ ہے۔ فائر اسٹور کوئیک اسٹارٹ سیٹ اپ کے عمل میں آپ کی رہنمائی کرتا ہے۔

کسی سابقہ NoSQL یا Firestore کے تجربے کی ضرورت نہیں ہے۔

متعلقہ سوچ: ایس کیو ایل ڈیٹا پر کیسے عمل کرتا ہے۔

ایک رشتہ دار ڈیٹا بیس میں، ڈیٹا کو واضح تعلقات سے منسلک جدولوں میں منظم کیا جاتا ہے۔ یہ نقطہ نظر پر انحصار کرتا ہے: معیاری کاری ڈیٹا ڈپلیکیشن کو ختم کریں۔

مثال کے طور پر، آپ اپنے ڈیٹا کو صارفین اور ان کے ممالک کو ذخیرہ کرنے کے لیے دو جدولوں میں تقسیم کرتے ہیں۔

Users: گرمی id (PK) last_name, first_name, #country_id (FK غیر ملکی کلید ہے)
Countries: گرمی country_id (PK) country_name

اس طرح کی ایک لائن کے ساتھ: 1, MINTOUMBA, Caleb, 1 کو Users اور 1, Canada کو Countriesغیر ملکی کلید خود بخود ہمیں بتاتی ہے کہ Caleb کینیڈا سے ہے۔ #country_id. ہمیں اندر "کینیڈا” کا لفظ لکھنے کی ضرورت نہیں تھی۔ Users میز خود.

ایس کیو ایل سمجھوتہ: تحریریں ہلکی ہیں (صرف ایک جگہ پر ڈیٹا کو اپ ڈیٹ کرنا)، لیکن پڑھنے کے لیے ڈیٹا بیس جوائن کی ضرورت ہوتی ہے (JOIN) جب بھی میں صارف کے ملک کا نام ظاہر کرنا چاہتا ہوں۔

یہ فائر اسٹور کے کام کرنے کے بالکل برعکس ہے، جیسا کہ ہم آگے دیکھیں گے۔

فائر اسٹور کا نمونہ: رشتہ دار NoSQL

فائر اسٹور NoSQL دستاویز کا ڈیٹا بیس – لفظی طور پر نہ صرف SQL. JSON جیسی دستاویزات کو جبری اسکیما کے بغیر مجموعوں میں جمع کریں۔

Firestore کی زیادہ تر تاریخ کے لیے، اس کا مطلب ہے کہ کوئی ڈیفالٹ جوائن نہیں ہوتا اور نہ ہی کوئی جوائن ہوتا ہے۔ GROUP BY. معیاری استفسار انجن نے اس کی حمایت نہیں کی، اور نہ ہی اس نے مزید جمع کرنے کی حمایت کی۔ count(), sum()اور average() یہ درخواست کوڈ میں ہونا تھا۔

یہ آج بھی سچ ہے۔ معیاری ایڈیشنیہ ڈیفالٹ رہے گا اور وہ ایپ ہے جس پر زیادہ تر موبائل/ویب ایپس چلیں گی اور جس ایپ پر ہم اس گائیڈ میں فوکس کریں گے۔

اس کے بعد، گوگل فائر اسٹور انٹرپرائز ایڈیشننئے کے ارد گرد عمارت پائپ لائن استفسار کا انجن اپریل 2026 میں عام دستیابی تک پہنچ گیا۔ پائپ لائن میں کثیر سطحی استفسار کا نحو اور سینکڑوں نئی خصوصیات شامل کی گئی ہیں، بشمول متعلقہ ذیلی سوالات کے ذریعے متعلقہ جوائنز اور اصل سوالات کے ذریعے متعلقہ جوائنز۔ aggregate(...) فائر اسٹور کو SQL کے برابر گروپ کرنے کے اقدامات GROUP BY.

کیا اس کا مطلب یہ ہے کہ ڈیٹا ماڈلنگ اب اہم نہیں رہی؟ یہ زیادہ تر ایپس پر لاگو نہیں ہوتا ہے۔ پائپ لائن کے سوالات 60 سیکنڈ کے ٹائم آؤٹ اور 128 MiB ورکنگ میموری کی حد کے اندر چلتے ہیں، جب کوئی انڈیکس موجود نہیں ہوتا ہے تو مکمل کلیکشن اسکینز پر واپس آسکتا ہے، اور اہم بات یہ ہے کہ انٹرپرائز ایڈیشن ریئل ٹائم سننے والوں اور آف لائن سپورٹ کو چھوڑ دیتا ہے (جس پر زیادہ تر Firestore کلائنٹ ایپس انحصار کرتی ہیں)۔

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

اگر آپ معیاری ایڈیشن میں ایک عام کلائنٹ کا سامنا کرنے والی ایپ بنا رہے ہیں، تو ذیل میں سرایت کرنے اور غیر معمولی بنانے کی حکمت عملی اب بھی تعلقات کو ماڈل کرنے کا طریقہ ہے۔

لیکن NoSQL کا مطلب "کوئی تعلق” نہیں ہے۔ معیاری ایڈیشن میں بھی۔ آپ مجموعہ کے درمیان مضبوط تعلقات استوار کر سکتے ہیں اور کرنا چاہیے۔ فرق یہ ہے کہ Firestore اسے مندرجہ ذیل طریقے سے نافذ یا حل نہیں کرتا ہے۔ JOIN یہ بطور ڈیفالٹ کیا جاتا ہے۔ جب تک کہ آپ پائپ لائن پر مبنی جوائنز کے لیے خاص طور پر انٹرپرائز ایڈیشن کا انتخاب نہیں کرتے، یہ آپ پر منحصر ہے کہ آپ ان تعلقات کو واضح طور پر استوار کریں اور استفسار کریں اور ایپلیکیشن کوڈ یا کلاؤڈ فنکشنز کے ذریعے ڈیٹا کی سالمیت کو برقرار رکھیں۔

بنیادی عمارت کے بلاکس: دستاویزات اور مجموعہ

اسکیما کو ڈیزائن کرنے سے پہلے، آئیے Firestore کے دو بنیادی اجزاء کی وضاحت کرتے ہیں:

دستاویز: اسٹوریج کی بنیادی اکائی۔ یہ JSON نما آبجیکٹ ہے جس کی شناخت ایک منفرد ID سے ہوتی ہے اور اس میں ٹائپ شدہ فیلڈز (سٹرنگز، نمبرز، بولین، ٹائم اسٹیمپ، جیو پوائنٹس، یا دیگر دستاویزات کے حوالے) ہوتے ہیں۔
مجموعہ: ایک کنٹینر جو دستاویزات رکھتا ہے۔ ایس کیو ایل ٹیبلز کے برعکس، ایک ہی مجموعہ میں موجود دستاویزات کو ایک ہی ڈھانچے کا اشتراک کرنے کی ضرورت نہیں ہے۔

فائر اسٹور کو جو چیز منفرد بناتی ہے وہ اس کی درجہ بندی کی نوعیت ہے۔ دستاویزات میں ذیلی جمع ہو سکتے ہیں۔مزید دستاویزات پر مشتمل ہے، اور خود مزید ذیلی مجموعوں پر مشتمل ہوسکتا ہے۔

اوپر دیے گئے خاکے میں، جڑ ہے۔ posts مجموعہ دستاویزات پر مشتمل ہے۔ post_001اپنے طور پر comments انفرادی تبصرے کی دستاویزات پر مشتمل ذیلی مجموعے۔ comment_001 اور comment_002. آپ مجموعوں اور دستاویزات کو کئی سطحوں تک گہرا کر سکتے ہیں، لیکن جیسا کہ ہم بعد میں دیکھیں گے، ایسا نہ کرنا بہتر ہے۔

اہم قوانین: بنیادی دستاویز کو پڑھتے وقت ذیلی مجموعے خود بخود دریافت نہیں ہوتے ہیں۔ ایس کیو ایل کے برعکس JOINذیلی مجموعہ کو پڑھنے کے لیے ہمیشہ ایک الگ، واضح استفسار کی ضرورت ہوتی ہے۔

سنہری اصول: پڑھنے کا ایک نمونہ، لکھنے کا نہیں۔

NoSQL ماڈلنگ میں یہ واحد سب سے اہم تصور ہے، اور جسے SQL ڈویلپر اکثر بھول جاتے ہیں۔ اپنے ڈیٹا کی ساخت اس بنیاد پر بنائیں کہ آپ کی ایپ ڈیٹا سے کیسے استفسار کرتی ہے، نہ کہ اسے کیسے ریکارڈ کیا جاتا ہے۔

کوئی بھی ڈیٹا بیس کوڈ لکھنے سے پہلے اپنے آپ سے پوچھیں:

میری ایپ میں کون سی اسکرینیں یہ ڈیٹا دکھاتی ہیں؟
کیا اس ڈیٹا کی خود ضرورت ہے، یا یہ ہمیشہ دوسرے ڈیٹا کے ساتھ مل کر ضروری ہے؟
کیا میں اس معلومات کو لکھنے یا اپ ڈیٹ کرنے سے کہیں زیادہ پڑھتا ہوں؟

پڑھنے کے لیے بہتر بنائیں اگر صارف آپ کے مصنف کا پروفائل 10,000 بار دیکھتا ہے جب بھی مصنف اپنا صارف نام اپ ڈیٹ کرتا ہے۔ دوسرے لفظوں میں، صارف نام کو براہ راست ہر پوسٹ کے اندر نقل کریں۔ یہ SQL instinct کے بالکل برعکس ہے جو ہم نے پہلے دیکھا تھا۔ یعنی، فالتو پن سے بچنے کے لیے پہلے معمول پر لائیں، چاہے پڑھنا زیادہ بھاری ہوجائے۔

ایمبیڈنگز اور حوالہ جات (غیر نارملائزیشن)

Firestore میں تعلقات کی نمائندگی کرنے کے لیے دو بنیادی حکمت عملی ہیں:

اختیار A: داخل کریں (گھوںسلا)

متعلقہ ڈیٹا کو براہ راست بنیادی دستاویز کے اندر ایک صف یا نقشہ (آبجیکٹ) کے طور پر اسٹور کریں۔

// A post with its comments embedded
{
  title: "Introduction to Firestore",
  author: "Caleb",
  comments: [
    { user: "Ama", text: "Great post!" },
    { user: "Kofi", text: "Thanks for the examples" }
  ]
}

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

اختیار B: حوالہ (غیر معمولی)

اداروں کو الگ الگ مجموعوں یا ذیلی مجموعوں میں تقسیم کریں اور دوسری پڑھنے سے بچنے کے لیے جان بوجھ کر کچھ فیلڈز کی نقل بنائیں۔

// posts/post_001
{
  title: "Introduction to Firestore",
  authorId: "uid_123",
  authorName: "Caleb",      // denormalized: avoids a second read to "users"
  authorAvatar: "https://...",
  commentCount: 12          // denormalized counter
}

// posts/post_001/comments/comment_001
{
  userId: "uid_456",
  userName: "Ama",
  text: "Great post!",
  createdAt: Timestamp
}

یہ مصنف کے نام اور اوتار کو ہر پوسٹ پر نقل کرے گا، لہذا آپ کو مزید پڑھنے کی ضرورت نہیں ہے۔ users جب بھی آپ پوسٹس کی فہرست دیکھیں۔

یہ ڈی نارملائزیشن ہے۔ ہم تیز پڑھنے کے لیے کنٹرول شدہ فالتو پن کی اجازت دیتے ہیں، جو SQL نارملائزیشن کے بالکل برعکس ہے۔ لاگت یہ ہے کہ اگر صارف اپنا نام تبدیل کرتا ہے تو ان کاپیوں کو اپ ڈیٹ کرنا ضروری ہے۔ یہ عام طور پر کلاؤڈ فنکشن کے ذریعہ سنبھالا جاتا ہے جو اس وقت متحرک ہوتا ہے جب: users دستاویزات کو اپ ڈیٹ کر دیا گیا ہے)۔

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

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

چاہے دیئے گئے فیلڈ کو غیر معمولی بنائیں یہ چیزوں کو مطابقت پذیر رکھنے کی قیمت پر منحصر ہے، نہ کہ وہ کتنی بار تبدیل ہوتی ہیں۔ ایک کاؤنٹر جو ایٹمی اضافے میں اپ ڈیٹ ہوتا ہے (commentCount, likeCount) کے ساتھ مطابقت پذیری کے لیے کوئی دوسری کاپیاں نہیں ہیں، لہذا کسی بھی فریکوئنسی پر اسے غیر معمولی بنانا سستا ہے۔

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

رشتہ ماڈلنگ کے طریقے (1-1، 1-N، NN)

ون آن ون (1-1)

فیلڈز کو ایک ہی دستاویز میں شامل کریں یا بالکل اسی دستاویز کی ID کا استعمال کرتے ہوئے الگ الگ مجموعوں میں ذخیرہ کریں۔ users/uid_123 اور privateProfiles/uid_123. یہ عوامی ڈیٹا کو حساس ڈیٹا سے الگ کرنے کے لیے مثالی ہے جس کے لیے مختلف حفاظتی اصولوں کی ضرورت ہوتی ہے۔

ایک سے کئی (1-N)

حجم اور استفسار کی سمت کے لحاظ سے تین اہم اختیارات ہیں:

کوئی راستہ نہیں ذیلی مجموعہ (posts/post_001/comments/*) تبصروں سے استفسار کرنے کے لیے تقریباً ہمیشہ مثالی ہوتا ہے۔ کے ذریعے یہ سب سے اوپر کی پوسٹیں ہیں اور ان کا حجم زیادہ ہو سکتا ہے۔
کوئی راستہ نہیں حوالوں کے ساتھ جڑوں کا مجموعہ (comments اور postId فیلڈ) مفید ہے جب آپ کو پوسٹ سے الگ الگ کسی مخصوص صارف کے تمام تبصروں سے استفسار کرنے کی ضرورت ہو (where("userId", "==", uid))۔
استعمال کریں سرایت شدہ صف صرف اس صورت میں جب حجم چھوٹا اور محدود رہے (اوپر اختیار A دیکھیں)

کئی سے کئی (NN)

یہ NoSQL کے بارے میں سب سے مشکل چیز ہے کیونکہ SQL کی طرح کوئی آٹو جوائننگ ٹیبل نہیں ہے۔ تین عمومی نمونے ہیں:

(1)۔ چوراہا مجموعہ SQL پیوٹ ٹیبل کی طرح۔

// memberships/{membershipId}
{
  userId: "uid_123",
  groupId: "group_789",
  role: "admin",
  joinedAt: Timestamp
}

اس کے بعد آپ اس سے استفسار کر سکتے ہیں۔ .where("userId", "==", uid) ان تمام گروپس کو تلاش کرنے کے لیے جن سے صارف کا تعلق ہے۔ .where("groupId", "==", gid) گروپ کے تمام ممبران کو تلاش کرنے کے لیے

(2)۔ دونوں طرف ID سرنی (کراس ڈی نارملائزیشن):

// users/uid_123      -> groupIds: ["group_789", "group_456"]
// groups/group_789   -> memberIds: ["uid_123", "uid_456"]

دونوں طرف سے پڑھنا تیز ہے، لیکن اسے ان فہرستوں کے لیے محفوظ رکھیں جہاں 1MB دستاویز کی حد اور طویل صفوں کو جوہری طور پر اپ ڈیٹ کرنے کی لاگت آپ کو بڑے پیمانے پر سزا دیتی ہے۔

(3)۔ ہائبرڈ نقطہ نظریہ اصل میں سب سے عام پیٹرن ہے. یعنی، ہلکے وزن والے رشتوں کی ایک صف جو شاذ و نادر ہی ہم منصبوں (صارفین کی پسندیدہ پوسٹس) کے ذریعے پوچھ گچھ کی جاتی ہے اور ان رشتوں کے لیے جوڑوں کا مجموعہ جو اکثر دونوں سمتوں میں پوچھے جاتے ہیں اور اکثر تبدیلی کا شکار ہوتے ہیں (ٹیم کے اراکین)۔

بہترین طریقوں اور نقصانات سے بچنے کے لیے

گھوںسلا کی گہرائی کی حد: Firestore آپ کو غیر معینہ مدت کے لیے ذیلی جمع کرنے کی اجازت دیتا ہے، لیکن دو یا تین سطحوں سے آگے سوالات اور حفاظتی اصولوں کو برقرار رکھنا واقعی مشکل ہو جاتا ہے۔ اگر ممکن ہو تو، ساخت کو ہموار کرنے کے لیے حوالہ جات استعمال کرنا اچھا خیال ہے۔
خود بخود بڑھی ہوئی دستاویز IDs سے پرہیز کریں۔ ترتیب وار ID (user_1, user_2, user_3…) کا سبب بن سکتا ہے۔ ہاٹ سپاٹ: انڈیکس کی ایک تنگ رینج میں ڈھیر لکھتا ہے، پیمانے پر کارکردگی کو کم کرتا ہے۔ جب تک آپ کے پاس کوئی معقول وجہ نہ ہو، فائر اسٹور کو بے ترتیب، یکساں طور پر تقسیم شدہ IDs بنانے دیں۔
جامع اشاریہ جات کے ساتھ محتاط رہیں۔ کوئی بھی استفسار جو متعدد آئٹمز کو یکجا کرتا ہے۔ .where() فلٹر یا .where() اور .orderBy() دیگر شعبوں کو جامع اشاریہ جات کی ضرورت ہوتی ہے۔ اسے پروڈکشن میں دریافت کرنے کے بجائے ڈیزائن کے دوران اس کے لیے منصوبہ بنائیں (فائر اسٹور کے غلطی کے پیغامات میں خود بخود گمشدہ اشاریہ جات بنانے کے لیے براہ راست روابط شامل ہیں)۔
"گرم” دستاویزات کی تحریری رفتار پر توجہ دیں۔ زیادہ سے زیادہ تجویز کردہ مسلسل ایک دستاویز کے لیے لکھنے کی رفتار تقریباً ہے۔ فی سیکنڈ 1 لکھیں۔. مثال کے طور پر، وہ دستاویزات جو عالمی صارفین کے ذریعہ کثرت سے اپ ڈیٹ ہوتی ہیں، جیسے کاؤنٹر، اس سے پہلے ایک رکاوٹ بن جائیں گے۔ Firestore ان کو قطار میں لگا کر مختصر برسٹ (5، 10، یا 50 رائٹ فی سیکنڈ) کو جذب کر سکتا ہے، لیکن کوئی بھی مسلسل ٹریفک جو زیادہ سے زیادہ 1 تحریر/سیکنڈ سے زیادہ ہے تنازعہ کی غلطیاں پیدا کرنا شروع کر دے گی۔ معیاری طے ہے۔ کٹے ہوئے کاؤنٹر: گنتی کو متعدد ذیلی دستاویزات میں تقسیم کریں اور پڑھتے وقت ان کا مجموعہ کریں۔
جان بوجھ کر ذیلی جمع استعمال کریں۔ آسان، لیکن ہمیشہ ایک علیحدہ استفسار کی ضرورت ہوتی ہے۔ تقریباً ہمیشہ، اگر آپ کو ڈیٹا ایک ساتھ درکار ہوتا ہے، ایمبیڈنگ یا ڈی نارملائزیشن بہتر کارکردگی کا مظاہرہ کرتی ہے۔
اپنے ڈیٹا ماڈل کے ساتھ حفاظتی اصولوں کو ڈیزائن کریں۔ فائر اسٹور میں حفاظتی اصول (firestore.rules) اسکیما کے ساتھ ہی ڈیزائن کیا جانا چاہئے۔ ایک ناقص سوچا ہوا ڈھانچہ عام طور پر درست قواعد لکھنا زیادہ مشکل بنا دیتا ہے۔

کیس اسٹڈی: توسیع پذیر بلاگ ڈیٹا بیس کو ڈیزائن کرنا

آئیے اس گائیڈ کے تمام اصولوں کو ایک ٹھوس مثال کے ساتھ دیکھیں: پوسٹس، تبصروں اور پسندیدگیوں والا بلاگ۔

// posts/{postId}
{
  title: "Modeling Firestore",
  slug: "modeling-firestore",
  authorId: "uid_123",
  authorName: "Caleb",         // denormalized: avoids a second read to "users"
  content: "...",
  tags: ["firebase", "nosql"], // embedded: small, bounded list
  commentCount: 3,             // denormalized counter
  likeCount: 47,               // denormalized counter (shard it if traffic is high)
  createdAt: Timestamp
}

// posts/{postId}/comments/{commentId}  → sub-collection: read together with the post
{
  userId: "uid_456",
  userName: "Ama",
  text: "Excellent article",
  createdAt: Timestamp
}

// likes/{likeId}  → root collection + reference
{                    // lets you quickly check if ONE user liked ONE post
  postId: "post_001",
  userId: "uid_456"
}

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

نتیجہ

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

Firestore میں ماڈلنگ ڈیٹا ایک مختلف نحو کے ساتھ متعلقہ عادات کو لاگو کرنے کے بارے میں نہیں ہے۔ یہ ایپ کے پڑھنے کے پیٹرن کے ارد گرد سوچنے کا بالکل مختلف طریقہ ہے۔

ہمیشہ پوچھیں، "میں اس ڈیٹا کو کیسے اور کتنی بار پڑھوں گا؟” شامل، حوالہ، یا ذیلی مجموعہ کے درمیان انتخاب کرنے سے پہلے۔ نیز، پروڈکشن میں دریافت کرنے کے بجائے، ڈیزائن کے مرحلے سے Firestore کی مخصوص حدود (1 MB فی دستاویز، پیچیدہ انڈیکس، ہاٹ اسپاٹنگ) کو ذہن میں رکھیں۔

پڑھنے کی سادگی اور لکھنے کی لاگت کے درمیان توازن وہی ہے جو فائر اسٹور ڈیٹا بیس کو الگ کرتا ہے جو اس ڈیٹا بیس سے خوبصورتی سے پیمانہ کرتا ہے جسے آپ اب سے چھ ماہ بعد دوبارہ تعمیر کریں گے۔