Messenger տվյալների բազա (մաս 1). բազային շրջանակի նախագծում

Ինչպես կարող եք բիզնեսի պահանջները թարգմանել կոնկրետ տվյալների կառուցվածքների՝ օգտագործելով զրոյից մեսենջերի տվյալների բազայի նախագծման օրինակը:

• Մաս 1. բազային շրջանակի ձևավորում
• Մաս 2. բաժին «շահույթի համար»

Մեր բազան այդքան մեծ և բաշխված չի լինի, ինչպես VKontakte-ն կամ Badoo, բայց «այնպես որ լիներ», բայց լավ էր՝ ֆունկցիոնալ, արագ և տեղավորվում է մեկ սերվերի վրա PostgreSQL - այնպես, որ դուք կարող եք տեղակայել ծառայության առանձին օրինակ ինչ-որ մի կողմում, օրինակ:

Հետևաբար, մենք չենք անդրադառնա հարդինգի, կրկնօրինակման և աշխարհաբաշխված համակարգերի խնդիրներին, այլ կկենտրոնանանք տվյալների բազայի ներսում շրջանային լուծումների վրա։

Քայլ 1. Որոշ բիզնես առանձնահատկություններ

Մենք վերացականորեն չենք ձևավորի մեր հաղորդագրությունները, այլ այն կինտեգրենք շրջակա միջավայրին կորպորատիվ սոցիալական ցանց. Այսինքն՝ մեր ժողովուրդը ոչ թե «ուղղակի նամակագրություն» է անում, այլ շփվում է միմյանց հետ որոշակի բիզնես խնդիրների լուծման համատեքստում։

Իսկ ի՞նչ խնդիրներ ունի բիզնեսը... Դիտարկենք զարգացման բաժնի պետ Վասիլի օրինակը։

• «Նիկոլայ, այս առաջադրանքի համար մեզ այսօր կարկատ է պետք»:
  Սա նշանակում է, որ նամակագրությունը կարող է իրականացվել որոշների համատեքստում փաստաթուղթը.
• «Կոլյա, դու գնալու ես Դոթա այս երեկո»:
  Այսինքն՝ նույնիսկ մեկ զույգ զրուցակիցները կարող են միաժամանակ շփվել տարբեր թեմաներով.
• «Պիտեր, Նիկոլայ, հավելվածում փնտրեք նոր սերվերի գնացուցակը»:
  Այսպիսով, մեկ հաղորդագրություն կարող է ունենալ մի քանի հասցեատերեր. Այս դեպքում հաղորդագրությունը կարող է պարունակել Կցված ֆայլեր.
• «Սեմյոն, մի հատ էլ նայիր»։
  Իսկ առկա նամակագրության մեջ մտնելու հնարավորություն պետք է լինի հրավիրել նոր անդամ.

Առայժմ անդրադառնանք «ակնհայտ» կարիքների այս ցանկին:

Չհասկանալով խնդրի կիրառական առանձնահատկությունները և դրան տրված սահմանափակումները, դիզայն արդյունավետ տվյալների բազայի սխեման լուծել այն գրեթե անհնար է:

Քայլ 2. Նվազագույն տրամաբանական միացում

Մինչ այժմ ամեն ինչ շատ նման է էլեկտրոնային նամակագրությանը` ավանդական բիզնես գործիք: Այո, «ալգորիթմորեն» շատ բիզնես խնդիրներ նման են միմյանց, հետևաբար դրանց լուծման գործիքները կառուցվածքային առումով նման են լինելու։

Ֆիքսենք սուբյեկտների հարաբերությունների արդեն ստացված տրամաբանական դիագրամը։ Մեր մոդելն ավելի հեշտ հասկանալի դարձնելու համար մենք կօգտագործենք ցուցադրման ամենապրիմիտիվ տարբերակը ER մոդելներ առանց UML կամ IDEF նշումների բարդությունների.

Մեր օրինակում ֆայլի անձը, փաստաթուղթը և երկուական «մարմինը» «արտաքին» սուբյեկտներ են, որոնք գոյություն ունեն ինքնուրույն՝ առանց մեր ծառայության: Հետևաբար, մենք դրանք ապագայում պարզապես կընկալենք որպես UUID-ի կողմից «ինչ-որ տեղ» հղումներ։

Ոչ ոքի որքան հնարավոր է պարզ դիագրամներ - Մարդկանց մեծ մասը, ում դուք ցույց կտաք նրանց, UML/IDEF կարդալու մասնագետ չեն: Բայց համոզվեք, որ նկարեք:

Քայլ 3. Սեղանի կառուցվածքի ուրվագիծը

Աղյուսակների և դաշտերի անունների մասինԴաշտերի և աղյուսակների «ռուսական» անվանումներին կարելի է այլ կերպ վերաբերվել, բայց դա ճաշակի հարց է։ Քանի որ այստեղ՝ Tensor-ում չկան օտարերկրյա մշակողներ, և PostgreSQL-ը մեզ թույլ է տալիս անուններ տալ նույնիսկ հիերոգլիֆներով, եթե դրանք փակցված չակերտների մեջ, ապա նախընտրում ենք օբյեկտները անվանել միանշանակ և հստակ, որպեսզի անհամապատասխանություններ չլինեն։
Քանի որ շատերը մեզ միանգամից հաղորդագրություններ են գրում, նրանցից ոմանք նույնիսկ կարող են դա անել անցանց, ապա ամենապարզ տարբերակն է օգտագործել UUID-ները որպես նույնացուցիչներ ոչ միայն արտաքին սուբյեկտների, այլ նաև մեր ծառայության ներսում գտնվող բոլոր օբյեկտների համար: Ավելին, դրանք կարող են ստեղծվել նույնիսկ հաճախորդի կողմից. սա կօգնի մեզ աջակցել հաղորդագրությունների ուղարկմանը, երբ տվյալների բազան ժամանակավորապես անհասանելի է, և բախման հավանականությունը չափազանց ցածր է:

Մեր տվյալների բազայի աղյուսակի նախագծի կառուցվածքը կունենա հետևյալ տեսքը.
Սեղաններ՝ 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)
);

Այստեղ մենք կիրառել ենք երկու բնորոշ մոտեցում, որոնք օգտագործվում են օժանդակ աղյուսակներ ստեղծելիս.

• Գրառումների բազմապատկում
  Օգտագործելով մեկ սկզբնական հաղորդագրության գրառումը, մենք ստեղծում ենք մի քանի հաջորդական գրառումներ տարբեր տեսակի գրանցամատյաններում տարբեր սեփականատերերի համար՝ ինչպես ուղարկողի, այնպես էլ ստացողի համար: Բայց ռեգիստրներից յուրաքանչյուրն այժմ ընկնում է ինդեքսի վրա, ի վերջո, սովորական դեպքում մենք կցանկանանք տեսնել միայն առաջին էջը:
• Եզակի ռեկորդներ
  Ամեն անգամ, երբ հաղորդագրություն եք ուղարկում կոնկրետ թեմայի շրջանակներում, բավական է ստուգել, ​​թե արդյոք այդպիսի գրառում արդեն կա։ Եթե ​​ոչ, ավելացրեք այն մեր «բառարանին»:

Հոդվածի հաջորդ մասում կխոսենք բաժանման իրականացում մեր տվյալների բազայի կառուցվածքում:

Source: www.habr.com