Basis data Messenger (bagean 1): ngrancang kerangka dhasar

Carane sampeyan bisa nerjemahake syarat bisnis menyang struktur data tartamtu nggunakake conto ngrancang database utusan saka ngeruk.

• Bagean 1: ngrancang pigura dhasar
• Bagean 2: bagean "kanggo laba"

Basis kita ora bakal gedhe lan disebarake, kaya VKontakte utawa Badoo, nanging "supaya dadi", nanging apik - fungsi, cepet lan pas ing siji server PostgreSQL - supaya sampeyan bisa masang conto kapisah saka layanan nang endi wae ing sisih, contone,.

Mulane, kita ora bakal ndemek masalah sharding, replikasi lan sistem geo-distribusi, nanging bakal fokus ing solusi sirkuit nang database.

Langkah 1: Sawetara spesifik bisnis

Kita ora bakal ngrancang olahpesen kanthi abstrak, nanging bakal nggabungake menyang lingkungan jaringan sosial perusahaan. Tegese, wong kita ora "mung cocog," nanging komunikasi karo siji liyane ing konteks ngrampungake masalah bisnis tartamtu.

Lan apa tugas bisnis?.. Ayo ndeleng conto Vasily, kepala departemen pangembangan.

• "Nikolai, kanggo tugas iki kita butuh tambalan dina iki!"
  Iki tegese korespondensi bisa ditindakake ing konteks sawetara dokumen.
• "Kolya, sampeyan arep dota sore iki?"
  Tegese, malah siji pasangan interlocutors bisa komunikasi bebarengan ing macem-macem topik.
• "Peter, Nikolay, deleng lampiran kanggo dhaptar rega server anyar."
  Dadi, siji pesen bisa duwe sawetara panampa. Ing kasus iki, pesen bisa ngemot File sing digandhengake.
• "Semyon, delengen uga."
  Lan kudu ana kesempatan kanggo mlebu menyang korespondensi sing ana ngajak anggota anyar.

Ayo dadi manggon ing dhaftar iki "jelas" kabutuhan kanggo saiki.

Tanpa mangerteni spesifik sing ditrapake masalah lan watesan sing diwenehake, desain efektif skema database kanggo ngatasi iku meh mokal.

Langkah 2: Sirkuit Logika Minimal

Nganti saiki, kabeh kerjane meh padha karo korespondensi email - alat bisnis tradisional. Ya, "algoritma" akeh masalah bisnis sing padha, mula alat kanggo ngrampungake bakal padha kanthi struktural.

Ayo ndandani diagram logis hubungan entitas sing wis dipikolehi. Kanggo nggawe model luwih gampang dingerteni, kita bakal nggunakake pilihan tampilan paling primitif model ER tanpa komplikasi notasi UML utawa IDEF:

Ing conto kita, wong, dokumen lan binar "awak" file kasebut minangka entitas "eksternal" sing ana kanthi mandiri tanpa layanan kita. Mulane, kita mung bakal ndeleng wong-wong mau ing mangsa ngarep minangka sawetara pranala "nang endi wae" dening UUID.

Nggambar diagram minangka prasaja sabisa - umume wong sing bakal dituduhake ora ahli maca UML / IDEF. Nanging manawa kanggo nggambar.

Langkah 3: Sketsa struktur tabel

Babagan jeneng tabel lan lapanganJeneng kolom lan tabel "Rusia" bisa dianggep beda, nanging iki minangka masalah rasa. Amarga ing kene ing Tensor ora ana pangembang asing, lan PostgreSQL ngidini kita menehi jeneng sanajan ing hieroglif, yen padha katutup ing kuotasi, banjur kita luwih seneng menehi jeneng obyek kanthi jelas lan jelas supaya ora ana bedane.
Amarga akeh wong sing nulis pesen menyang kita bebarengan, sawetara wong bisa uga nindakake iki offline, banjur pilihan sing paling gampang yaiku nggunakake UUID minangka pengenal ora mung kanggo entitas eksternal, nanging uga kanggo kabeh obyek ing layanan kita. Kajaba iku, bisa digawe sanajan ing sisih klien - iki bakal mbantu kita ndhukung ngirim pesen nalika database ora kasedhiya kanggo sementara, lan kemungkinan tabrakan sithik banget.

Struktur tabel draf ing database kita bakal katon kaya iki:
Tabel: 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
);

Tabel: 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
);

Wangsulan: Bab ingkang paling gampang nalika njlèntrèhaké format kanggo miwiti "unwinding" graph sambungan saka tabel sing ora dirujuk awake dhewe ora marang sapa-sapa.

Langkah 4: Temokake kabutuhan sing ora jelas

Sing, kita wis dirancang database sing bisa nulis sampurna lan piye wae maca.

Ayo kita nyelehake ing posisi pangguna layanan kita - apa sing arep kita lakoni?

• Pesen pungkasan
  iki kronologis diurutake pendaptaran pesen "ku" adhedhasar macem-macem kritéria. Ing ngendi aku minangka salah sawijining panampa, ing ngendi aku dadi penulis, ing ngendi dheweke nulis marang aku lan aku ora mangsuli, ing ngendi dheweke ora mangsuli aku, ...
• Peserta korespondensi
  Sapa sing melu chatting dawa iki?

Struktur kita ngidini kita ngrampungake loro masalah kasebut "umum", nanging ora cepet. Masalah iku kanggo ngurutake ing tugas pisanan ora bisa nggawe indeks, cocog kanggo saben peserta (lan sampeyan kudu ngekstrak kabeh cathetan), lan kanggo ngatasi sing nomer loro sampeyan kudu extract kabeh pesen ing topik iki.

Tugas pangguna sing ora disengaja bisa nggawe kandel salib ing produktivitas.

Langkah 5: Denormalisasi Smart

Loro-lorone masalah kita bakal ditanggulangi kanthi tabel tambahan sing bakal ditindakake bagean duplikat saka data, perlu kanggo mbentuk indeks sing cocog kanggo tugas kita.


Tabel: RU

CREATE TABLE "РеестрСообщений"(
  "Владелец"
    uuid
, "ТипРеестра"
    smallint
, "ДатаВремя"
    timestamp
, "Сообщение"
    uuid
, PRIMARY KEY("Владелец", "ТипРеестра", "Сообщение")
);
CREATE INDEX ON "РеестрСообщений"("Владелец", "ТипРеестра", "ДатаВремя" DESC);

CREATE TABLE "УчастникТемы"(
  "Тема"
    uuid
, "Персона"
    uuid
, PRIMARY KEY("Тема", "Персона")
);

Tabel: 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)
);

Ing kene kita wis ngetrapake rong pendekatan khas sing digunakake nalika nggawe tabel tambahan:

• Multiply cathetan
  Nggunakake siji cathetan pesen dhisikan, kita nggawe sawetara cathetan tindakake-munggah ing macem-macem jinis ndhaftar kanggo pamilik beda - loro kanggo pangirim lan panampa. Nanging saben ndhaptar saiki ana ing indeks - sawise kabeh, ing kasus sing khas, kita mung pengin ndeleng kaca pisanan.
• cathetan unik
  Saben sampeyan ngirim pesen ing topik tartamtu, cukup kanggo mriksa apa entri kasebut wis ana. Yen ora, tambahake menyang "kamus".

Ing bagean sabanjure artikel kita bakal ngomong babagan implementasi partisi menyang struktur database kita.

Source: www.habr.com