Pangkalan data Messenger (bahagian 1): mereka bentuk rangka kerja asas

Bagaimana anda boleh menterjemah keperluan perniagaan ke dalam struktur data tertentu menggunakan contoh mereka bentuk pangkalan data utusan dari awal.

• Bahagian 1: mereka bentuk bingkai asas
• Bahagian 2: pembahagian "untuk keuntungan"

Pangkalan kami tidak akan sebesar dan diedarkan, seperti VKontakte atau Badoo, tetapi "supaya ia adalah", tetapi ia adalah baik - berfungsi, pantas dan muat pada satu pelayan PostgreSQL - supaya anda boleh menggunakan contoh perkhidmatan yang berasingan di suatu tempat di sebelah, sebagai contoh.

Oleh itu, kami tidak akan menyentuh isu perpecahan, replikasi dan sistem teragihan geo, tetapi akan memberi tumpuan kepada penyelesaian litar di dalam pangkalan data.

Langkah 1: Beberapa spesifik perniagaan

Kami tidak akan mereka bentuk pemesejan kami secara abstrak, tetapi akan menyepadukannya ke dalam persekitaran rangkaian sosial korporat. Maksudnya, orang kita tidak "hanya berkoresponden," tetapi berkomunikasi antara satu sama lain dalam konteks menyelesaikan masalah perniagaan tertentu.

Dan apakah tugas perniagaan?.. Mari kita lihat contoh Vasily, ketua jabatan pembangunan.

• "Nikolai, untuk tugas ini kita memerlukan tampalan hari ini!"
  Ini bermakna surat-menyurat boleh dijalankan dalam konteks sesetengah pihak dokumen.
• "Kolya, adakah anda akan pergi ke Dota petang ini?"
  Maksudnya, sepasang lawan bicara pun boleh berkomunikasi secara serentak mengenai pelbagai topik.
• "Peter, Nikolay, lihat dalam lampiran untuk senarai harga untuk pelayan baharu."
  Jadi, satu mesej boleh ada beberapa penerima. Dalam kes ini, mesej mungkin mengandungi Fail yang dilampirkan.
• "Semyon, lihat juga."
  Dan harus ada peluang untuk memasuki surat-menyurat yang sedia ada jemput ahli baru.

Mari kita memikirkan senarai keperluan "jelas" ini buat masa ini.

Tanpa memahami spesifikasi masalah yang digunakan dan batasan yang diberikan kepadanya, reka bentuk berkesan skema pangkalan data untuk menyelesaikannya hampir mustahil.

Langkah 2: Litar Logik Minimum

Setakat ini, semuanya berfungsi hampir sama dengan surat-menyurat e-mel - alat perniagaan tradisional. Ya, "secara algoritma" banyak masalah perniagaan adalah serupa antara satu sama lain, oleh itu alat untuk menyelesaikannya akan serupa dari segi struktur.

Mari kita betulkan rajah logik perhubungan entiti yang telah diperolehi. Untuk menjadikan model kami lebih mudah difahami, kami akan menggunakan pilihan paparan yang paling primitif model ER tanpa komplikasi notasi UML atau IDEF:

Dalam contoh kami, orang, dokumen dan "badan" binari fail adalah entiti "luaran" yang wujud secara bebas tanpa perkhidmatan kami. Oleh itu, kami hanya akan menganggapnya pada masa hadapan sebagai beberapa pautan "di suatu tempat" oleh UUID.

Lukis gambar rajah semudah mungkin - kebanyakan orang yang anda akan tunjukkan kepada mereka bukanlah pakar dalam membaca UML/IDEF. Tetapi pastikan anda melukis.

Langkah 3: Melakar struktur jadual

Mengenai nama jadual dan medanNama medan dan jadual "Rusia" boleh dilayan secara berbeza, tetapi ini adalah soal rasa. Kerana ia di sini di Tensor tiada pembangun asing, dan PostgreSQL membenarkan kami memberi nama walaupun dalam hieroglif, jika mereka disertakan dalam petikan, maka kami lebih suka menamakan objek dengan jelas dan jelas supaya tidak ada percanggahan.
Memandangkan ramai orang menulis mesej kepada kami serentak, sesetengah daripada mereka mungkin melakukan ini luar talian, maka pilihan yang paling mudah ialah gunakan UUID sebagai pengecam bukan sahaja untuk entiti luar, tetapi juga untuk semua objek dalam perkhidmatan kami. Selain itu, ia boleh dijana walaupun pada sisi pelanggan - ini akan membantu kami menyokong penghantaran mesej apabila pangkalan data tidak tersedia buat sementara waktu, dan kemungkinan perlanggaran adalah sangat rendah.

Struktur jadual draf dalam pangkalan data kami akan kelihatan seperti ini:
Jadual : 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
);

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

Perkara paling mudah apabila menerangkan format adalah untuk mula "membubarkan" graf sambungan daripada jadual yang tidak dirujuk diri mereka kepada sesiapa pun.

Langkah 4: Ketahui keperluan yang tidak jelas

Itu sahaja, kami telah mereka pangkalan data di mana anda boleh menulis dengan sempurna dan entah bagaimana membaca.

Mari letakkan diri kita dalam kedudukan pengguna perkhidmatan kami - apa yang kita mahu lakukan dengannya?

• Mesej terakhir
  ini disusun mengikut kronologi pendaftaran mesej "saya" berdasarkan pelbagai kriteria. Di mana saya adalah salah seorang penerima, di mana saya adalah pengarang, di mana mereka menulis kepada saya dan saya tidak menjawab, di mana mereka tidak menjawab saya, ...
• Peserta surat-menyurat
  Siapa yang turut serta dalam sembang panjang dan panjang ini?

Struktur kami membolehkan kami menyelesaikan kedua-dua masalah ini "secara umum," tetapi tidak dengan cepat. Masalahnya ialah untuk menyusun dalam tugas pertama tidak dapat mencipta indeks, sesuai untuk setiap peserta (dan anda perlu mengeluarkan semua rekod), dan untuk menyelesaikan yang kedua yang anda perlukan ekstrak semua mesej mengenai topik ini.

Tugas pengguna yang tidak diingini boleh meletakkan huruf tebal silang pada produktiviti.

Langkah 5: Penyahnormalan Pintar

Kedua-dua masalah kami akan diselesaikan dengan jadual tambahan di mana kami akan menyelesaikannya bahagian pendua data, perlu untuk membentuk pada mereka indeks yang sesuai untuk tugas kita.


Jadual : RU

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

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

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

Di sini kami telah menggunakan dua pendekatan biasa yang digunakan semasa membuat jadual tambahan:

• Mendarab rekod
  Menggunakan satu rekod mesej awal, kami mencipta beberapa rekod susulan dalam jenis daftar yang berbeza untuk pemilik yang berbeza - untuk pengirim dan untuk penerima. Tetapi setiap daftar kini jatuh pada indeks - lagipun, dalam kes biasa, kami hanya mahu melihat halaman pertama.
• Rekod unik
  Setiap kali anda menghantar mesej dalam topik tertentu, sudah cukup untuk menyemak sama ada entri sedemikian sudah wujud. Jika tidak, tambahkannya pada "kamus" kami.

Dalam bahagian seterusnya artikel kita akan bercakap tentang pelaksanaan pembahagian ke dalam struktur pangkalan data kami.

Sumber: www.habr.com