میسنجر ڈیٹا بیس (حصہ 1): بیس فریم ورک کو ڈیزائن کرنا

میسنجر ڈیٹا بیس کو شروع سے ڈیزائن کرنے کی مثال کا استعمال کرتے ہوئے آپ کس طرح کاروباری ضروریات کو مخصوص ڈیٹا ڈھانچے میں ترجمہ کر سکتے ہیں۔

• حصہ 1: بیس فریم ڈیزائن کرنا
• حصہ 2: سیکشننگ "منافع کے لیے"

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

لہذا، ہم شارڈنگ، نقل اور جیو ڈسٹری بیوٹڈ سسٹمز کے مسائل پر توجہ نہیں دیں گے، بلکہ ڈیٹا بیس کے اندر موجود سرکٹ سلوشنز پر توجہ مرکوز کریں گے۔

مرحلہ 1: کچھ کاروباری تفصیلات

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

اور کاروبار کے کیا کام ہیں؟... آئیے ڈیولپمنٹ ڈیپارٹمنٹ کے سربراہ واسیلی کی مثال دیکھتے ہیں۔

• "نکولائی، اس کام کے لیے ہمیں آج ایک پیچ کی ضرورت ہے!"
  اس کا مطلب یہ ہے کہ کچھ کے تناظر میں خط و کتابت کی جا سکتی ہے۔ دستاویز.
• "کولیا، کیا تم آج شام دوٹا جا رہے ہو؟"
  یعنی بات چیت کرنے والوں کا ایک جوڑا بھی بیک وقت بات چیت کر سکتا ہے۔ مختلف موضوعات پر.
• "پیٹر، نکولے، نئے سرور کے لیے قیمت کی فہرست کے اٹیچمنٹ میں دیکھیں۔"
  تو، ایک پیغام ہو سکتا ہے کئی وصول کنندگان. اس صورت میں، پیغام پر مشتمل ہو سکتا ہے منسلک فائلوں.
• "سیمیون، یہ بھی دیکھو۔"
  اور موجودہ خط و کتابت میں داخل ہونے کا موقع ملنا چاہیے۔ ایک نئے رکن کو مدعو کریں.

آئیے فی الحال "واضح" ضروریات کی اس فہرست پر غور کریں۔

مسئلے کی لاگو کردہ تفصیلات اور اس پر دی گئی حدود کو سمجھے بغیر، ڈیزائن مؤثر ڈیٹا بیس اسکیما کو حل کرنا تقریباً ناممکن ہے۔

مرحلہ 2: کم سے کم منطقی سرکٹ

اب تک، ہر چیز ای میل خط و کتابت سے ملتی جلتی ہے - ایک روایتی کاروباری ٹول۔ ہاں، "الگورتھمک طور پر" بہت سے کاروباری مسائل ایک دوسرے سے ملتے جلتے ہیں، اس لیے ان کو حل کرنے کے اوزار ساختی طور پر ایک جیسے ہوں گے۔

آئیے ہستی کے تعلقات کے پہلے سے حاصل شدہ منطقی خاکہ کو ٹھیک کرتے ہیں۔ اپنے ماڈل کو سمجھنے میں آسان بنانے کے لیے، ہم سب سے قدیم ڈسپلے آپشن استعمال کریں گے۔ ER ماڈلز UML یا IDEF اشارے کی پیچیدگیوں کے بغیر:

ہماری مثال میں، فائل کا فرد، دستاویز اور بائنری "باڈی" "بیرونی" ادارے ہیں جو ہماری سروس کے بغیر آزادانہ طور پر موجود ہیں۔ لہذا، ہم مستقبل میں انہیں UUID کے ذریعہ "کہیں کہیں" کے لنکس کے طور پر سمجھیں گے۔

ڈرا خاکے جتنا آسان ہو سکے - زیادہ تر لوگ جنہیں آپ انہیں دکھائیں گے وہ UML/IDEF پڑھنے کے ماہر نہیں ہیں۔ لیکن ڈرا ضرور کریں۔

مرحلہ 3: میز کی ساخت کا خاکہ بنانا

ٹیبل اور فیلڈ کے ناموں کے بارے میںکھیتوں اور میزوں کے "روسی" ناموں کو مختلف طریقے سے سمجھا جا سکتا ہے، لیکن یہ ذائقہ کا معاملہ ہے. کیونکہ یہاں Tensor پر کوئی غیر ملکی ڈویلپر نہیں ہیں، اور PostgreSQL ہمیں hieroglyphs میں بھی نام دینے کی اجازت دیتا ہے، اگر وہ حوالوں میں بند، پھر ہم اشیاء کو غیر مبہم اور واضح طور پر نام دینے کو ترجیح دیتے ہیں تاکہ کوئی تضاد نہ ہو۔
چونکہ بہت سے لوگ ہمیں ایک ہی وقت میں پیغامات لکھتے ہیں، ان میں سے کچھ ایسا بھی کر سکتے ہیں۔ آف لائن، پھر سب سے آسان آپشن ہے۔ UUIDs کو بطور شناخت کنندہ استعمال کریں۔ نہ صرف بیرونی اداروں کے لیے بلکہ ہماری سروس کے اندر موجود تمام اشیاء کے لیے بھی۔ مزید برآں، وہ کلائنٹ کی طرف سے بھی تیار کیے جاسکتے ہیں - اس سے ہمیں پیغامات بھیجنے میں مدد ملے گی جب ڈیٹا بیس عارضی طور پر دستیاب نہ ہو، اور تصادم کا امکان انتہائی کم ہو۔

ہمارے ڈیٹا بیس میں ڈرافٹ ٹیبل کا ڈھانچہ اس طرح نظر آئے گا:
میزیں: RU

CREATE TABLE "Тема"(
  "Тема"
    uuid
      PRIMARY KEY
, "Документ"
    uuid
, "Название"
    text
);

CREATE TABLE "Сообщение"(
  "Сообщение"
    uuid
      PRIMARY KEY
, "Тема"
    uuid
, "Автор"
    uuid
, "ДатаВремя"
    timestamp
, "Текст"
    text
);

CREATE TABLE "Адресат"(
  "Сообщение"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Сообщение", "Персона")
);

CREATE TABLE "Файл"(
  "Файл"
    uuid
      PRIMARY KEY
, "Сообщение"
    uuid
, "BLOB"
    uuid
, "Имя"
    text
);

میزیں: EN

CREATE TABLE theme(
  theme
    uuid
      PRIMARY KEY
, document
    uuid
, title
    text
);

CREATE TABLE message(
  message
    uuid
      PRIMARY KEY
, theme
    uuid
, author
    uuid
, dt
    timestamp
, body
    text
);

CREATE TABLE message_addressee(
  message
    uuid
, person
    uuid
, PRIMARY KEY(message, person)
);

CREATE TABLE message_file(
  file
    uuid
      PRIMARY KEY
, message
    uuid
, content
    uuid
, filename
    text
);

فارمیٹ کی وضاحت کرتے وقت سب سے آسان چیز یہ ہے کہ کنکشن گراف کو "ان وائنڈنگ" کرنا شروع کیا جائے۔ ان میزوں سے جن کا حوالہ نہیں دیا گیا ہے۔ خود کسی کو نہیں.

مرحلہ 4: غیر واضح ضروریات تلاش کریں۔

بس، ہم نے ایک ڈیٹا بیس تیار کیا ہے جس میں آپ بالکل ٹھیک لکھ سکتے ہیں۔ کسی طرح پڑھنے کے لئے.

آئیے خود کو ہماری خدمت کے صارف کے جوتے میں ڈالیں - ہم اس کے ساتھ کیا کرنا چاہتے ہیں؟

• آخری پیغامات
  یہ تاریخ کے مطابق ترتیب دیا گیا ہے۔ مختلف معیارات پر مبنی "میرے" پیغامات کی رجسٹری۔ جہاں میں وصول کنندگان میں سے ایک ہوں، جہاں میں مصنف ہوں، جہاں انہوں نے مجھے لکھا اور میں نے جواب نہیں دیا، جہاں انہوں نے مجھے جواب نہیں دیا، ...
• خط و کتابت کے شرکاء
  اس لمبی لمبی گفتگو میں کون کون حصہ لے رہا ہے؟

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

غیر ارادی صارف کے کام بولڈ ہوسکتے ہیں۔ پیداوری پر کراس.

مرحلہ 5: اسمارٹ ڈی نارملائزیشن

ہمارے دونوں مسائل اضافی جدولوں سے حل ہوں گے جن میں ہم کریں گے۔ ڈیٹا کا ڈپلیکیٹ حصہان پر ہمارے کاموں کے لیے موزوں اشاریے بنانے کے لیے ضروری ہے۔


میزیں: RU

CREATE TABLE "РеестрСообщений"(
  "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

CREATE TABLE "УчастникТемы"(
  "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

میزیں: EN

CREATE TABLE message_registry(
  owner
    uuid
, registry
    smallint
, dt
    timestamp
, message
    uuid
, PRIMARY KEY(owner, registry, message)
);
CREATE INDEX ON message_registry(owner, registry, dt DESC);

CREATE TABLE theme_participant(
  theme
    uuid
, person
    uuid
, PRIMARY KEY(theme, person)
);

یہاں ہم نے معاون میزیں بناتے وقت استعمال ہونے والے دو عام طریقوں کو لاگو کیا ہے:

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

مضمون کے اگلے حصے میں ہم بات کریں گے۔ تقسیم کا نفاذ ہمارے ڈیٹا بیس کی ساخت میں۔

ماخذ: www.habr.com