ميسينجر ڊيٽابيس (حصو 1): بنيادي فريم ورڪ کي ڊزائين ڪرڻ

توهان ڪئين ڪاروبار جي ضرورتن جو ترجمو ڪري سگهو ٿا مخصوص ڊيٽا جي جوڙجڪ ۾ مثال طور استعمال ڪندي هڪ ميسينجر ڊيٽابيس ٺاهڻ جي شروعات کان.

• حصو 1: بنيادي فريم ڊزائين ڪرڻ
• حصو 2: سيڪشننگ "نفعي لاء"

اسان جو بنياد ايترو وڏو ۽ ورهايل نه هوندو، VKontakte وانگر يا خراب, but “ so that it” , but it was good – functional, fast and ھڪڙي سرور تي ٺھيل PostgreSQL - انهي ڪري ته توهان خدمت جو هڪ الڳ مثال مقرر ڪري سگهو ٿا ڪنهن پاسي، مثال طور.

تنهن ڪري، اسان شارڊنگ، نقل ۽ جيو ورهايل سسٽم جي مسئلن تي رابطو نه ڪنداسين، پر ڊيٽابيس جي اندر سرڪٽ حل تي ڌيان ڏينداسين.

قدم 1: ڪجهه ڪاروباري خاصيتون

اسان پنهنجي پيغام کي خلاصي طور تي ڊزائين نه ڪنداسين، پر ان کي ماحول ۾ ضم ڪنداسين ڪارپوريٽ سماجي نيٽ ورڪ. اهو آهي، اسان جا ماڻهو ”صرف خط و ڪتابت“ نه ڪندا آهن، پر ڪجهه ڪاروباري مسئلن کي حل ڪرڻ جي سلسلي ۾ هڪ ٻئي سان رابطو ڪندا آهن.

۽ ڪاروبار جا ڪم ڪهڙا آهن؟... اچو ته واسيلي جو مثال ڏسون، ترقي کاتي جي سربراهه.

• "نيڪولائي، هن ڪم لاء اسان کي اڄ هڪ پيچ جي ضرورت آهي!"
  هن جو مطلب آهي ته correspondence ڪجهه جي حوالي سان منعقد ڪري سگهجي ٿو سند.
• ”ڪوليا، ڇا تون اڄ شام ڊاٽو وڃي رهيو آهين؟
  اهو آهي، جيتوڻيڪ هڪ جوڙو ڳالهائيندڙن جو هڪ ئي وقت ۾ گفتگو ڪري سگهي ٿو مختلف موضوعن تي.
• "پطرس، نيڪولي، نئين سرور جي قيمت جي فهرست جي منسلڪ ۾ ڏسو."
  تنهن ڪري، هڪ پيغام ٿي سگهي ٿو ڪيترائي وصول ڪندڙ. انهي حالت ۾، پيغام تي مشتمل ٿي سگھي ٿو ڳنڍيل فائلون.
• "سيميون، هڪ نظر پڻ وٺو."
  ۽ موجوده خط و ڪتابت ۾ داخل ٿيڻ جو موقعو هجڻ گهرجي نئين ميمبر کي دعوت ڏيو.

اچو ته ھاڻي ”واضح“ ضرورتن جي ھن لسٽ تي رھون.

مسئلي جي لاڳو ڪيل وضاحتن کي سمجھڻ کان سواء ۽ ان کي ڏنل حدون، ڊيزائن اثرائتو ان کي حل ڪرڻ لاء ڊيٽابيس اسڪيما لڳ ڀڳ ناممڪن آهي.

قدم 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