Messenger දත්ත සමුදාය (1 කොටස): මූලික රාමුව සැලසුම් කිරීම

මුල සිටම මැසෙන්ජර් දත්ත සමුදායක් සැලසුම් කිරීමේ උදාහරණය භාවිතා කරමින් ඔබට ව්‍යාපාරික අවශ්‍යතා විශේෂිත දත්ත ව්‍යුහයන් බවට පරිවර්තනය කළ හැකි ආකාරය.

• 1 කොටස: මූලික රාමුව සැලසුම් කිරීම
• 2 කොටස: "ලාභය සඳහා" කොටස් කිරීම

අපගේ පදනම එතරම් විශාල හා බෙදා හරිනු නොලැබේ, VKontakte වගේ හෝ බඩකො, නමුත් "එය එසේ විය", නමුත් එය හොඳයි - ක්රියාකාරී, වේගවත් සහ එක් සේවාදායකයකට ගැලපේ PostgreSQL - එවිට ඔබට සේවාවේ වෙනම අවස්ථාවක් පැත්තේ කොතැනක හෝ යෙදවිය හැක, උදාහරණයක් ලෙස.

එබැවින්, අපි බෙදා හැරීම, අනුකරණය සහ භූ-බෙදාහැරි පද්ධති පිළිබඳ ගැටළු ස්පර්ශ නොකරනු ඇත, නමුත් දත්ත සමුදාය තුළ ඇති පරිපථ විසඳුම් කෙරෙහි අවධානය යොමු කරන්නෙමු.

පියවර 1: සමහර ව්‍යාපාර විශේෂතා

අපි අපගේ පණිවිඩ යැවීම වියුක්ත ලෙස සැලසුම් නොකර, එය පරිසරයට ඒකාබද්ධ කරන්නෙමු ආයතනික සමාජ ජාලය. එනම්, අපේ මිනිසුන් "පමණක් අනුරූප" නොකරන නමුත් ඇතැම් ව්යාපාරික ගැටළු විසඳීමේ සන්දර්භය තුළ එකිනෙකා සමඟ සන්නිවේදනය කරයි.

සහ ව්‍යාපාරයක කාර්යයන් මොනවාද?.. අපි සංවර්ධන දෙපාර්තමේන්තුවේ ප්‍රධානියා වන වාසිලිගේ උදාහරණය බලමු.

• “නිකොලායි, මෙම කාර්යය සඳහා අපට අද පැච් එකක් අවශ්‍යයි!”
  මෙයින් අදහස් කරන්නේ සමහර අයගේ සන්දර්භය තුළ ලිපි හුවමාරු කර ගත හැකි බවයි ලියවිල්ල.
• "කෝල්යා, ඔයා අද හවස ඩෝටා යනවද?"
  එනම්, එක් අන්තර් සම්බන්ධක යුගලයකට පවා එකවර සන්නිවේදනය කළ හැකිය විවිධ මාතෘකා මත.
• "පීටර්, නිකොලායි, නව සේවාදායකය සඳහා මිල ලැයිස්තුව සඳහා ඇමුණුම බලන්න."
  එබැවින්, එක් පණිවිඩයක් තිබිය හැක ලබන්නන් කිහිප දෙනෙක්. මෙම අවස්ථාවේදී, පණිවිඩයේ අඩංගු විය හැක අමුණා ඇති ගොනු.
• "සෙමියන්, ඔබත් බලන්න."
  තවද පවතින ලිපි හුවමාරුවට ඇතුල් වීමට අවස්ථාවක් තිබිය යුතුය නව සාමාජිකයෙකුට ආරාධනා කරන්න.

අපි දැන් මෙම “පැහැදිලි” අවශ්‍යතා ලැයිස්තුවේ වාසය කරමු.

ගැටලුවේ ව්‍යවහාරික විශේෂතා සහ එයට ලබා දී ඇති සීමාවන් තේරුම් නොගෙන, නිර්මාණය කරන්න ඵලදායී එය විසඳීමට දත්ත සමුදා සැලැස්ම පාහේ කළ නොහැක්කකි.

පියවර 2: අවම තාර්කික පරිපථය

මෙතෙක්, සෑම දෙයක්ම විද්‍යුත් තැපැල් ලිපි හුවමාරුවට බෙහෙවින් සමාන ය - සාම්ප්‍රදායික ව්‍යාපාරික මෙවලමකි. ඔව්, "ඇල්ගොරිතමය" බොහෝ ව්යාපාරික ගැටළු එකිනෙකට සමාන වේ, එබැවින් ඒවා විසඳීම සඳහා මෙවලම් ව්යුහාත්මකව සමාන වනු ඇත.

ආයතන සම්බන්ධතා වල දැනටමත් ලබාගෙන ඇති තාර්කික රූප සටහන සවි කරමු. අපගේ ආකෘතිය තේරුම් ගැනීමට පහසු කිරීම සඳහා, අපි වඩාත් ප්‍රාථමික සංදර්ශක විකල්පය භාවිතා කරමු ER ආකෘති UML හෝ IDEF සටහන් වල සංකූලතා නොමැතිව:

අපගේ උදාහරණයේ දී, ගොනුවේ පුද්ගලයා, ලේඛනය සහ ද්විමය "ශරීරය" අපගේ සේවාව නොමැතිව ස්වාධීනව පවතින "බාහිර" ආයතන වේ. එමනිසා, අපි ඒවා අනාගතයේදී UUID මගින් “කොතැනක හෝ” සබැඳි ලෙස සරලව දකිමු.

අඳින්න හැකි තරම් සරල රූප සටහන් - ඔබ ඔවුන්ට පෙන්වන බොහෝ පුද්ගලයන් UML/IDEF කියවීමේ විශේෂඥයන් නොවේ. නමුත් ඇඳීමට වග බලා ගන්න.

පියවර 3: වගු ව්‍යුහය ඇඳීම

වගු සහ ක්ෂේත්‍ර නම් ගැනක්ෂේත්ර සහ වගු වල "රුසියානු" නම් වෙනස් ලෙස සැලකිය හැකිය, නමුත් මෙය රසය පිළිබඳ කාරණයකි. මන්දයත් මෙන්න Tensor එකේ විදේශීය සංවර්ධකයින් නොමැත, සහ 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: Smart Denormalization

අපගේ ගැටළු දෙකම අතිරේක වගු මගින් විසඳනු ඇත දත්තවල අනුපිටපත් කොටස, ඒවා මත අපගේ කාර්යයන් සඳහා සුදුසු දර්ශක සැකසීමට අවශ්‍ය වේ.


වගු: 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