មូលដ្ឋានទិន្នន័យ Messenger (ផ្នែកទី 1): ការរចនាក្របខ័ណ្ឌមូលដ្ឋាន

របៀបដែលអ្នកអាចបកប្រែតម្រូវការអាជីវកម្មទៅជារចនាសម្ព័ន្ធទិន្នន័យជាក់លាក់ដោយប្រើឧទាហរណ៍នៃការរចនាមូលដ្ឋានទិន្នន័យសារពីដំបូង។

• ផ្នែកទី 1: ការរចនាស៊ុមមូលដ្ឋាន
• ផ្នែកទី 2: ផ្នែក "សម្រាប់ប្រាក់ចំណេញ"

មូលដ្ឋានរបស់យើងនឹងមិនមានទំហំធំនិងចែកចាយ, ដូចជា VKontakte ឬ Badooប៉ុន្តែ "ដូច្នេះវាបាន" ប៉ុន្តែវាល្អ - មុខងារលឿននិង សមនៅលើម៉ាស៊ីនមេមួយ។ PostgreSQL - ដូច្នេះ​អ្នក​អាច​ដាក់​ពង្រាយ​ឧទាហរណ៍​ផ្សេង​ពី​គ្នា​នៃ​សេវា​នៅ​កន្លែង​ណា​មួយ​នៅ​ផ្នែក​ខាង​ជា​ឧទាហរណ៍។

ដូច្នេះហើយ យើងនឹងមិនប៉ះពាល់ដល់បញ្ហានៃការបែងចែក ការចម្លង និងប្រព័ន្ធចែកចាយតាមភូមិសាស្ត្រនោះទេ ប៉ុន្តែនឹងផ្តោតលើដំណោះស្រាយសៀគ្វីនៅខាងក្នុងមូលដ្ឋានទិន្នន័យ។

ជំហានទី 1: អាជីវកម្មជាក់លាក់មួយចំនួន

យើងនឹងមិនរចនាការផ្ញើសាររបស់យើងដោយអរូបីទេ ប៉ុន្តែនឹងបញ្ចូលវាទៅក្នុងបរិស្ថាន បណ្តាញសង្គមសាជីវកម្ម. នោះគឺប្រជាជនរបស់យើងមិន "គ្រាន់តែឆ្លើយឆ្លងគ្នា" ប៉ុន្តែទំនាក់ទំនងគ្នាទៅវិញទៅមកក្នុងបរិបទនៃការដោះស្រាយបញ្ហាអាជីវកម្មមួយចំនួន។

ហើយតើអាជីវកម្មមានភារកិច្ចអ្វីខ្លះ?.. តោះមើលឧទាហរណ៍របស់ Vasily ដែលជាប្រធាននាយកដ្ឋានអភិវឌ្ឍន៍។

• "នីកូឡៃ សម្រាប់កិច្ចការនេះ យើងត្រូវការបំណះថ្ងៃនេះ!"
  នេះមានន័យថាការឆ្លើយឆ្លងអាចត្រូវបានធ្វើឡើងនៅក្នុងបរិបទនៃមួយចំនួន ឯកសារ.
• "កូលីយ៉ា តើអ្នកនឹងទៅ Dota ល្ងាចនេះទេ?"
  នោះគឺសូម្បីតែ interlocutor មួយគូអាចទំនាក់ទំនងក្នុងពេលដំណាលគ្នា។ លើប្រធានបទផ្សេងៗ.
• "Peter, Nikolay រកមើលនៅក្នុងឯកសារភ្ជាប់សម្រាប់បញ្ជីតម្លៃសម្រាប់ម៉ាស៊ីនមេថ្មី។"
  ដូច្នេះសារមួយអាចមាន អ្នកទទួលជាច្រើន។. ក្នុងករណីនេះ សារអាចមាន ឯកសារ​ភ្ជាប់.
• “សេមយ៉ុន ចាំមើលផង”
  ហើយគួរតែមានឱកាសដើម្បីចូលទៅក្នុងការឆ្លើយឆ្លងដែលមានស្រាប់ អញ្ជើញសមាជិកថ្មី។.

ចូរយើងរស់នៅក្នុងបញ្ជីនៃតម្រូវការ "ជាក់ស្តែង" សម្រាប់ពេលនេះ។

ដោយមិនយល់ពីភាពជាក់លាក់ដែលបានអនុវត្តនៃបញ្ហា និងដែនកំណត់ដែលបានផ្តល់ឱ្យវា ការរចនា មានប្រសិទ្ធភាព គ្រោងការណ៍មូលដ្ឋានទិន្នន័យដើម្បីដោះស្រាយវាគឺស្ទើរតែមិនអាចទៅរួចទេ។

ជំហានទី 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