Messenger gagnagrunnur (hluti 1): hanna grunnramma

Hvernig þú getur þýtt viðskiptakröfur yfir í tiltekið gagnaskipulag með því að nota dæmið um að hanna boðberagagnagrunn frá grunni.

• Hluti 1: hanna grunngrind
• Hluti 2: skipting „í hagnaðarskyni“

Stöðin okkar verður ekki eins stór og dreifð, eins og VKontakte eða Badoo, en "svo að það var", en það var gott - hagnýtur, hratt og passa á einn netþjón PostgreSQL - svo að þú getir sent upp sérstakt tilvik af þjónustunni einhvers staðar á hliðinni, til dæmis.

Þess vegna munum við ekki snerta málefni klippingar, afritunar og landdreifðra kerfa, heldur munum við einbeita okkur að hringrásarlausnum inni í gagnagrunninum.

Skref 1: Sumar upplýsingar um viðskipti

Við munum ekki hanna skilaboðin okkar abstrakt heldur samþætta þau inn í umhverfið samfélagsnet fyrirtækja. Það er að segja, fólkið okkar „svarar ekki bara“ heldur hefur samskipti sín á milli í samhengi við að leysa ákveðin viðskiptavandamál.

Og hver eru verkefni fyrirtækis?.. Skoðum dæmi Vasily, yfirmanns þróunardeildar.

• „Nikolai, fyrir þetta verkefni þurfum við plástur í dag!
  Þetta þýðir að bréfaskipti geta átt sér stað í samhengi sumra skjalið.
• "Kolya, ætlarðu til Dota í kvöld?"
  Það er, jafnvel eitt par af viðmælendum getur átt samskipti samtímis um ýmis efni.
• „Peter, Nikolay, leitaðu í viðhenginu fyrir verðlista fyrir nýja netþjóninn.
  Svo, ein skilaboð geta haft nokkrir viðtakendur. Í þessu tilviki geta skilaboðin innihaldið Meðfylgjandi skrár.
• "Semyon, skoðaðu líka."
  Og það ætti að vera tækifæri til að fara í núverandi bréfaskipti bjóða nýjum meðlimi.

Við skulum dvelja við þennan lista yfir „augljósar“ þarfir í bili.

Án þess að skilja beitt sérstöðu vandamálsins og takmarkanir sem því eru gefnar, hönnun áhrifarík gagnagrunnsskema til að leysa það er nánast ómögulegt.

Skref 2: Lágmarks rökrás

Hingað til virkar allt mjög svipað og tölvupóstsamskipti - hefðbundið viðskiptatæki. Já, „algrímslega“ eru mörg viðskiptavandamál lík hvert öðru, þess vegna verða tækin til að leysa þau svipuð.

Við skulum laga rökrétt skýringarmynd sem þegar hefur verið fengin af tengslum eininga. Til að gera líkanið okkar auðveldara að skilja munum við nota frumstæðasta skjávalkostinn ER módel án fylgikvilla UML eða IDEF merkinga:

Í dæminu okkar eru manneskja, skjal og tvöfaldur „megin“ skráarinnar „ytri“ einingar sem eru til sjálfstætt án þjónustu okkar. Þess vegna munum við einfaldlega skynja þá í framtíðinni sem einhverja tengla „einhvers staðar“ eftir UUID.

Jafntefli skýringarmyndir eins einfaldar og mögulegt er - flestir sem þú munt sýna þá eru ekki sérfræðingar í að lesa UML/IDEF. En vertu viss um að teikna.

Skref 3: Skissa á töflubygginguna

Um töflu- og reitanöfnHægt er að meðhöndla „rússnesku“ nöfn reita og taflna á annan hátt, en þetta er smekksatriði. Vegna þess að hér á Tensor það eru engir erlendir forritarar, og PostgreSQL gerir okkur kleift að gefa nöfn jafnvel í híeróglyfum, ef þeir með gæsalappa, þá kjósum við að nefna hluti ótvírætt og skýrt þannig að það sé ekkert misræmi.
Þar sem margir skrifa okkur skilaboð í einu geta sumir þeirra jafnvel gert þetta án nettengingar, þá er einfaldasti kosturinn nota UUID sem auðkenni ekki aðeins fyrir utanaðkomandi aðila, heldur einnig fyrir alla hluti í þjónustu okkar. Þar að auki er hægt að búa til þau jafnvel á biðlarahlið - þetta mun hjálpa okkur að styðja við sendingu skilaboða þegar gagnagrunnurinn er tímabundið ófáanlegur og líkurnar á árekstri eru mjög litlar.

Drög að töfluuppbyggingu í gagnagrunninum okkar mun líta svona út:
Töflur: HR

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

Töflur: 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
);

Einfaldast þegar verið er að lýsa sniði er að byrja að „vinda ofan af“ tengingarritinu úr töflum sem ekki er vísað til sig engum.

Skref 4: Finndu út óljósar þarfir

Það er það, við höfum hannað gagnagrunn þar sem þú getur skrifað fullkomlega og einhvern veginn lesa.

Setjum okkur í spor notanda þjónustu okkar - hvað viljum við gera við hana?

• Síðustu skilaboðin
  Það raðað í tímaröð skrá yfir „mín“ skilaboð byggð á ýmsum forsendum. Þar sem ég er einn af viðtakendum, þar sem ég er höfundur, þar sem þeir skrifuðu mér og ég svaraði ekki, þar sem þeir svöruðu mér ekki, ...
• Þátttakendur bréfaskipta
  Hver er jafnvel að taka þátt í þessu langa, langa spjalli?

Uppbygging okkar gerir okkur kleift að leysa bæði þessi vandamál „almennt“ en ekki fljótt. Vandamálið er að fyrir flokkun innan fyrsta verkefnisins ekki hægt að búa til vísitölu, hentugur fyrir hvern þátttakanda (og þú verður að draga út allar skrárnar) og til að leysa seinni sem þú þarft draga út öll skilaboð um þetta efni.

Óviljandi verkefni notenda geta verið feitletruð kross á framleiðni.

Skref 5: Snjöll afeðlun

Bæði vandamál okkar verða leyst með viðbótartöflum þar sem við munum afrita hluta gagna, nauðsynlegt að mynda á þeim vísitölur sem henta verkefnum okkar.


Töflur: HR

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

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

Töflur: 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)
);

Hér höfum við beitt tveimur dæmigerðum aðferðum sem notaðar eru við að búa til aukatöflur:

• Margföldun met
  Með því að nota eina upphafsskilaboðaskrá búum við til nokkrar eftirfylgniskrár í mismunandi gerðum skráa fyrir mismunandi eigendur - bæði fyrir sendanda og viðtakanda. En hver skrár fellur nú á vísitöluna - þegar allt kemur til alls, í dæmigerðu tilviki, viljum við aðeins sjá fyrstu síðuna.
• Einstök met
  Í hvert skipti sem þú sendir skilaboð innan tiltekins efnis er nóg að athuga hvort slík færsla sé þegar til. Ef ekki skaltu bæta því við „orðabókina“ okkar.

Í næsta hluta greinarinnar munum við tala um framkvæmd skiptingar inn í uppbyggingu gagnagrunnsins okkar.

Heimild: www.habr.com