മെസഞ്ചർ ഡാറ്റാബേസ് (ഭാഗം 1): അടിസ്ഥാന ചട്ടക്കൂട് രൂപകൽപ്പന ചെയ്യുന്നു

സ്ക്രാച്ചിൽ നിന്ന് ഒരു മെസഞ്ചർ ഡാറ്റാബേസ് രൂപകൽപ്പന ചെയ്യുന്നതിന്റെ ഉദാഹരണം ഉപയോഗിച്ച് നിങ്ങൾക്ക് എങ്ങനെ ബിസിനസ് ആവശ്യകതകൾ നിർദ്ദിഷ്ട ഡാറ്റ ഘടനകളിലേക്ക് വിവർത്തനം ചെയ്യാം.

• ഭാഗം 1: അടിസ്ഥാന ഫ്രെയിം രൂപകൽപ്പന ചെയ്യുന്നു
• ഭാഗം 2: "ലാഭത്തിനുവേണ്ടി" എന്ന വിഭാഗം

ഞങ്ങളുടെ അടിത്തറ വലുതും വിതരണം ചെയ്യപ്പെടുന്നതുമല്ല, VKontakte പോലെ അഥവാ ബാദു, എന്നാൽ "അങ്ങനെയായിരുന്നു", എന്നാൽ അത് നല്ലതായിരുന്നു - പ്രവർത്തനക്ഷമവും വേഗതയേറിയതും ഒരു സെർവറിൽ യോജിക്കുന്നു PostgreSQL - അതുവഴി നിങ്ങൾക്ക് സേവനത്തിന്റെ ഒരു പ്രത്യേക ഉദാഹരണം വശത്ത് എവിടെയെങ്കിലും വിന്യസിക്കാനാകും, ഉദാഹരണത്തിന്.

അതിനാൽ, ഷാർഡിംഗ്, റെപ്ലിക്കേഷൻ, ജിയോ ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റങ്ങൾ എന്നിവയുടെ പ്രശ്നങ്ങളിൽ ഞങ്ങൾ സ്പർശിക്കില്ല, പക്ഷേ ഡാറ്റാബേസിനുള്ളിലെ സർക്യൂട്ട് സൊല്യൂഷനുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കും.

ഘട്ടം 1: ചില ബിസിനസ്സ് പ്രത്യേകതകൾ

ഞങ്ങൾ ഞങ്ങളുടെ സന്ദേശമയയ്‌ക്കൽ അമൂർത്തമായി രൂപകൽപ്പന ചെയ്യില്ല, മറിച്ച് അതിനെ പരിസ്ഥിതിയുമായി സംയോജിപ്പിക്കും കോർപ്പറേറ്റ് സോഷ്യൽ നെറ്റ്‌വർക്ക്. അതായത്, നമ്മുടെ ആളുകൾ "വെറും പൊരുത്തപ്പെടുന്നില്ല", എന്നാൽ ചില ബിസിനസ്സ് പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന്റെ പശ്ചാത്തലത്തിൽ പരസ്പരം ആശയവിനിമയം നടത്തുന്നു.

പിന്നെ ഒരു ബിസിനസിന്റെ ചുമതലകൾ എന്തൊക്കെയാണ്?.. വികസന വകുപ്പ് മേധാവി വാസിലിയുടെ ഉദാഹരണം നോക്കാം.

• “നിക്കോളായ്, ഈ ടാസ്‌ക്കിനായി ഞങ്ങൾക്ക് ഇന്ന് ഒരു പാച്ച് ആവശ്യമാണ്!”
  ചിലരുടെ പശ്ചാത്തലത്തിൽ കത്തിടപാടുകൾ നടത്താമെന്നാണ് ഇതിനർത്ഥം രേഖ.
• “കോല്യ, നിങ്ങൾ ഇന്ന് വൈകുന്നേരം ഡോട്ടയിലേക്ക് പോകുകയാണോ?”
  അതായത്, ഒരു ജോടി ഇന്റർലോക്കുട്ടറുകൾക്ക് പോലും ഒരേസമയം ആശയവിനിമയം നടത്താൻ കഴിയും വിവിധ വിഷയങ്ങളിൽ.
• "പീറ്റർ, നിക്കോളായ്, പുതിയ സെർവറിനായുള്ള വില പട്ടികയുടെ അറ്റാച്ച്മെന്റിൽ നോക്കുക."
  അതിനാൽ, ഒരു സന്ദേശമുണ്ടാകാം നിരവധി സ്വീകർത്താക്കൾ. ഈ സാഹചര്യത്തിൽ, സന്ദേശത്തിൽ അടങ്ങിയിരിക്കാം അറ്റാച്ച് ചെയ്ത ഫയലുകൾ.
• "സെമിയോൺ, നീയും നോക്കൂ."
  നിലവിലുള്ള കത്തിടപാടുകളിൽ പ്രവേശിക്കാനുള്ള അവസരവും ഉണ്ടായിരിക്കണം ഒരു പുതിയ അംഗത്തെ ക്ഷണിക്കുക.

ഇപ്പോൾ "വ്യക്തമായ" ആവശ്യകതകളുടെ ഈ പട്ടികയിൽ നമുക്ക് താമസിക്കാം.

പ്രശ്നത്തിന്റെ പ്രായോഗിക പ്രത്യേകതകളും അതിന് നൽകിയിരിക്കുന്ന പരിമിതികളും മനസ്സിലാക്കാതെ, ഡിസൈൻ ചെയ്യുക ഫലപ്രദമായ ഇത് പരിഹരിക്കുന്നതിനുള്ള ഡാറ്റാബേസ് സ്കീമ മിക്കവാറും അസാധ്യമാണ്.

ഘട്ടം 2: മിനിമൽ ലോജിക് സർക്യൂട്ട്

ഇതുവരെ, എല്ലാം ഇമെയിൽ കത്തിടപാടുകൾക്ക് സമാനമാണ് - ഒരു പരമ്പരാഗത ബിസിനസ്സ് ഉപകരണം. അതെ, "അൽഗോരിതമനുസരിച്ച്" പല ബിസിനസ്സ് പ്രശ്നങ്ങളും പരസ്പരം സമാനമാണ്, അതിനാൽ അവ പരിഹരിക്കുന്നതിനുള്ള ഉപകരണങ്ങൾ ഘടനാപരമായി സമാനമായിരിക്കും.

എന്റിറ്റി ബന്ധങ്ങളുടെ ഇതിനകം ലഭിച്ച ലോജിക്കൽ ഡയഗ്രം ശരിയാക്കാം. ഞങ്ങളുടെ മോഡൽ മനസ്സിലാക്കുന്നത് എളുപ്പമാക്കുന്നതിന്, ഞങ്ങൾ ഏറ്റവും പ്രാകൃതമായ ഡിസ്പ്ലേ ഓപ്ഷൻ ഉപയോഗിക്കും ER മോഡലുകൾ UML അല്ലെങ്കിൽ IDEF നൊട്ടേഷനുകളുടെ സങ്കീർണതകളില്ലാതെ:

ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, ഫയലിന്റെ വ്യക്തി, പ്രമാണം, ബൈനറി "ബോഡി" എന്നിവ ഞങ്ങളുടെ സേവനമില്ലാതെ സ്വതന്ത്രമായി നിലനിൽക്കുന്ന "ബാഹ്യ" എന്റിറ്റികളാണ്. അതിനാൽ, UUID-യുടെ "എവിടെയെങ്കിലും" ചില ലിങ്കുകളായി ഞങ്ങൾ ഭാവിയിൽ അവയെ മനസ്സിലാക്കും.

വരയ്ക്കുക കഴിയുന്നത്ര ലളിതമായ ഡയഗ്രമുകൾ - നിങ്ങൾ അവരെ കാണിക്കുന്ന മിക്ക ആളുകളും UML/IDEF വായിക്കുന്നതിൽ വിദഗ്ധരല്ല. എന്നാൽ വരയ്ക്കാൻ ശ്രദ്ധിക്കുക.

ഘട്ടം 3: പട്ടികയുടെ ഘടന വരയ്ക്കുന്നു

പട്ടികയെയും ഫീൽഡ് നാമങ്ങളെയും കുറിച്ച്ഫീൽഡുകളുടെയും ടേബിളുകളുടെയും "റഷ്യൻ" പേരുകൾ വ്യത്യസ്തമായി പരിഗണിക്കാം, പക്ഷേ ഇത് രുചിയുടെ കാര്യമാണ്. എന്തുകൊണ്ടെന്നാല് ഇവിടെ ടെൻസറിൽ വിദേശ ഡെവലപ്പർമാരില്ല, കൂടാതെ ഹൈറോഗ്ലിഫുകളിൽ പോലും പേരുകൾ നൽകാൻ PostgreSQL ഞങ്ങളെ അനുവദിക്കുന്നു. ഉദ്ധരണികളിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, പിന്നെ പൊരുത്തക്കേടുകൾ ഉണ്ടാകാതിരിക്കാൻ വ്യക്തവും വ്യക്തവുമായ ഒബ്‌ജക്‌റ്റുകൾക്ക് പേരിടാൻ ഞങ്ങൾ താൽപ്പര്യപ്പെടുന്നു.
നിരവധി ആളുകൾ ഞങ്ങൾക്ക് ഒരേസമയം സന്ദേശങ്ങൾ എഴുതുന്നതിനാൽ, അവരിൽ ചിലർ ഇത് ചെയ്തേക്കാം ഓഫ്‌ലൈൻ, അപ്പോൾ ഏറ്റവും ലളിതമായ ഓപ്ഷൻ ആണ് ഐഡന്റിഫയറായി UUID-കൾ ഉപയോഗിക്കുക ബാഹ്യ എന്റിറ്റികൾക്ക് മാത്രമല്ല, ഞങ്ങളുടെ സേവനത്തിനുള്ളിലെ എല്ലാ ഒബ്ജക്റ്റുകൾക്കും. മാത്രമല്ല, അവ ക്ലയന്റ് വശത്ത് പോലും സൃഷ്ടിക്കാൻ കഴിയും - ഡാറ്റാബേസ് താൽക്കാലികമായി ലഭ്യമല്ലാത്തപ്പോൾ സന്ദേശങ്ങൾ അയയ്‌ക്കുന്നതിനെ പിന്തുണയ്ക്കാൻ ഇത് ഞങ്ങളെ സഹായിക്കും, ഒപ്പം കൂട്ടിയിടി ഉണ്ടാകാനുള്ള സാധ്യത വളരെ കുറവുമാണ്.

ഞങ്ങളുടെ ഡാറ്റാബേസിലെ ഡ്രാഫ്റ്റ് ടേബിൾ ഘടന ഇതുപോലെ കാണപ്പെടും:
പട്ടികകൾ: 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