மெசஞ்சர் தரவுத்தளம் (பகுதி 1): அடிப்படை கட்டமைப்பை வடிவமைத்தல்

புதிதாக ஒரு மெசஞ்சர் தரவுத்தளத்தை வடிவமைப்பதற்கான உதாரணத்தைப் பயன்படுத்தி, வணிகத் தேவைகளை குறிப்பிட்ட தரவு கட்டமைப்புகளில் எவ்வாறு மொழிபெயர்க்கலாம்.

• பகுதி 1: அடிப்படை சட்டத்தை வடிவமைத்தல்
• பகுதி 2: "லாபத்திற்காக" பிரிவு

எங்கள் தளம் பெரியதாகவும் விநியோகிக்கப்படவும் இருக்காது, VKontakte போன்றது அல்லது Badoo, ஆனால் "அப்படி இருந்தது", ஆனால் அது நன்றாக இருந்தது - செயல்பாட்டு, வேகமான மற்றும் ஒரு சர்வரில் பொருந்தும் 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