Messenger datu-basea (1. zatia): oinarrizko markoa diseinatzea

Nola itzul ditzakezu negozio-eskakizunak datu-egitura zehatzetara mezularitzako datu-base bat hutsetik diseinatzearen adibidea erabiliz.

• 1. zatia: oinarrizko markoa diseinatzea
• 2. zatia: "irabazirako" sekzioa

Gure oinarria ez da hain handia eta banatua izango, VKontakte bezala edo Badoo, baina "horrela izan zen", baina ona zen - funtzionala, azkarra eta zerbitzari batean sartu PostgreSQL - alboko nonbait zerbitzuaren instantzia bereizi bat zabaldu ahal izateko, adibidez.

Hori dela eta, ez ditugu zatiketa, erreplikazio eta geo-banatutako sistemen gaiak ukituko, datu-basearen barruko zirkuituen soluzioetan oinarrituko gara.

1. urratsa: negozioaren xehetasun batzuk

Ez dugu gure mezularitza abstraktuki diseinatuko, baizik eta ingurunean integratuko dugu sare sozial korporatiboa. Hau da, gure jendea ez da "bakarrik bat egiten", baizik eta elkarren artean komunikatzen da negozio-arazo jakin batzuk konpontzeko testuinguruan.

Eta zeintzuk dira enpresa baten zereginak?... Ikus dezagun Vasilyren adibidea, garapen saileko burua.

• "Nikolai, zeregin honetarako adabaki bat behar dugu gaur!"
  Horrek esan nahi du korrespondentzia batzuen testuinguruan egin daitekeela dokumentua.
• "Kolya, gaur arratsaldean Dotara joango zara?"
  Hau da, solaskide bikote batek ere aldi berean komunikatu daitezke hainbat gairi buruz.
• "Peter, Nikolay, begiratu zerbitzari berriaren prezioen zerrenda eranskinean."
  Beraz, mezu batek izan dezake hainbat hartzaile. Kasu honetan, mezuak eduki dezake Erantsitako fitxategiak.
• "Semyon, begiratu ere bai."
  Eta lehendik dagoen korrespondentzian sartzeko aukera egon beharko litzateke kide berri bat gonbidatu.

Goazen oraingoz behar “ageriko” zerrenda honetan.

Arazoaren zehaztapen aplikatuak eta horri ematen zaizkion mugak ulertu gabe, diseinua eraginkorra datu-basearen eskema konpontzea ia ezinezkoa da.

2. urratsa: Zirkuitu logiko minimoa

Orain arte, dena posta elektronikoko korrespondentziaren oso antzekoa da - negozio-tresna tradizionala. Bai, "algoritmikoki" negozio-arazo asko elkarren antzekoak dira, beraz, horiek konpontzeko tresnak estrukturalki antzekoak izango dira.

Konpon dezagun jada lortutako entitate-erlazioen diagrama logikoa. Gure eredua errazago ulertzeko, bistaratzeko aukerarik primitiboena erabiliko dugu ER ereduak UML edo IDEF notazioen konplikaziorik gabe:

Gure adibidean, fitxategiaren pertsona, dokumentua eta "gorputza" bitarra gure zerbitzurik gabe modu independentean dauden "kanpo" entitateak dira. Hori dela eta, etorkizunean UUID-en "nonbait" lotura batzuk bezala hautemango ditugu.

Marraztu diagramak ahalik eta errazenak - Erakutsiko diezun pertsona gehienak ez dira UML/IDEF irakurtzen adituak. Baina ziurtatu marrazten duzula.

3. urratsa: taularen egituraren zirriborroa egitea

Taulen eta eremuen izenei buruzEremu eta taulen "errusiako" izenak modu ezberdinean trata daitezke, baina hau gustu kontua da. Zeren hemen Tensor-en ez dago atzerriko garatzailerik, eta PostgreSQL-k izenak hieroglifoetan ere emateko aukera ematen digu, baldin eta komatxo artean sartuta, orduan nahiago dugu objektuak anbiguotasunik gabe eta argi izendatzea, desadostasunik egon ez dadin.
Jende askok aldi berean mezuak idazten dizkigunez, horietako batzuek hau ere egin dezakete lineaz kanpo, orduan aukerarik errazena da erabili UUIDak identifikatzaile gisa kanpoko entitateentzat ez ezik, gure zerbitzuaren barruko objektu guztientzat ere bai. Gainera, bezeroaren aldetik ere sor daitezke; honek datu-basea aldi baterako erabilgarri ez dagoenean mezuak bidaltzen lagunduko digu eta talka izateko probabilitatea oso txikia denean.

Gure datu-baseko taularen zirriborroaren egitura honela izango da:
Taulak: 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
);

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

Formatu bat deskribatzean gauzarik errazena konexio grafikoa "asaltzen" hastea da erreferentziarik ez duten tauletatik beraiek inori.

4. urratsa: Agerikoak ez diren beharrak ezagutu

Hori da, datu-base bat diseinatu dugu zeinetan primeran idatzi dezakezun eta nolabait irakurri.

Jar gaitezen gure zerbitzuaren erabiltzailearen larruan - zer egin nahi dugu horrekin?

• Azken mezuak
  It kronologikoki ordenatuta hainbat irizpidetan oinarritutako “nire” mezuen erregistroa. Non nagoen hartzaileetako bat, non nagoen egilea, non idatzi zidaten eta ez nion erantzun, non ez zidaten erantzun,...
• Korrespondentziako partaideak
  Nor ari da parte hartzen berriketa luze eta luze honetan?

Gure egiturak bi arazo hauek "oro har" konpontzeko aukera ematen digu, baina ez azkar. Arazoa lehen zereginaren barruan ordenatzea da ezin da indizea sortu, parte hartzaile bakoitzarentzat egokia (eta erregistro guztiak atera beharko dituzu), eta behar duzun bigarrena konpontzeko atera mezu guztiak gai honi buruz.

Nahi gabeko erabiltzaileen atazek lodia jarri dezakete produktibitatea gurutzatu.

5. urratsa: Desnormalizazio adimenduna

Gure arazo biak egingo ditugun taula gehigarrien bidez konponduko dira datuen zati bat bikoiztu, beharrezkoak horien gainean gure zereginetarako egokiak diren indizeak osatzeko.


Taulak: RU

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

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

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

Hemen taula laguntzaileak sortzeko erabiltzen diren bi ikuspegi tipiko aplikatu ditugu:

• Erregistroak biderkatzea
  Hasierako mezu-erregistro bat erabiliz, hainbat jarraipen-erregistro sortzen ditugu erregistro mota desberdinetan jabe ezberdinentzat - bai igorlearentzat bai hartzailearentzat. Baina erregistro bakoitza aurkibidean erortzen da orain; azken finean, kasu tipiko batean, lehen orrialdea bakarrik ikusi nahi dugu.
• Erregistro bereziak
  Gai zehatz baten barruan mezu bat bidaltzen duzun bakoitzean, nahikoa da sarrera hori existitzen den egiaztatzea. Hala ez bada, gehitu gure "hiztegira".

Artikuluaren hurrengo zatian hitz egingo dugu zatiketa ezartzea gure datu-basearen egituran sartu.

Iturria: www.habr.com