Cele mai bune practici de proiectare a bazelor de date pentru aplicații de înaltă performanță

Pentru ca o aplicație să aibă o performanță bună, aveți nevoie de un server de aplicații puternic, o lățime de bandă mare și garantată și o muncă de programare bine făcută. Există însă un aspect care nu este întotdeauna luat în considerare și care are de obicei un impact mare asupra performanței oricărei aplicații: proiectarea bazei de date.

Vom analiza acum cele mai bune practici de proiectare a bazelor de date pentru a ne asigura că accesul la date nu este un blocaj care afectează negativ performanța aplicației.

Care este scopul unei bune baze de date?

Pe lângă îmbunătățirea performanței accesului la date, un design bun aduce și alte beneficii, cum ar fi menținerea coerenței, acurateței și fiabilității datelor și reducerea spațiului de stocare prin eliminarea redundanțelor. Un alt avantaj al unui design bun este că baza de date este mai ușor de utilizat și de întreținut. Oricine trebuie să-l gestioneze va trebui doar să se uite la diagrama entitate-relație (ERD) pentru a înțelege structura acesteia.

ERD-urile sunt instrumentul fundamental de proiectare a bazelor de date. Ele pot fi create și vizualizate la trei niveluri de design: conceptual , logic și fizic .

Designul conceptual prezintă o diagramă foarte rezumată, cu doar elementele necesare pentru a conveni asupra criteriilor cu părțile interesate ale proiectului, care nu trebuie să înțeleagă detaliile tehnice ale bazei de date. Designul logic arată entitățile și relațiile lor în detaliu, dar într-un mod independent de baza de date.

Există multe instrumente pe care le puteți utiliza pentru a facilita proiectarea bazelor de date din ERD-uri. Printre cele mai bune sunt DbSchema , SqlDBM și Vertabelo .

DbSchema

DbSchema vă permite să proiectați și să gestionați vizual baze de date SQL, NoSQL sau Cloud. Instrumentul vă permite să proiectați schema pe un computer și să o implementați în mai multe baze de date și să generați documentație în diagrame HTML5, să scrieți interogări și să explorați vizual datele, printre altele. De asemenea, oferă sincronizarea schemei, generarea aleatorie de date și editarea codului SQL cu completare automată.

SqlDBM

SqlDBM este unul dintre cele mai bune instrumente de proiectare a diagramei bazei de date, deoarece oferă o modalitate ușoară de a vă proiecta baza de date în orice browser. Nu este nevoie de alt motor de bază de date sau instrumente de modelare pentru a-l utiliza, deși SqlDBM vă permite să importați o schemă dintr-o bază de date existentă. Este ideal pentru lucrul în echipă, deoarece vă permite să împărtășiți proiecte de design cu colegii.

Vertabelo

Vertabelo este un instrument de proiectare a bazelor de date vizuale online care vă permite să proiectați o bază de date în mod logic și să derivați automat schema fizică. Poate face inginerie inversă, poate genera diagrame din bazele de date existente și poate controla accesul la diagrame prin diferențierea privilegiilor de acces pentru proprietari, editori și vizualizatori.

În cele din urmă, designul fizic este cel care adaugă ERD-ului toate detaliile necesare pentru a-l transforma într-o bază de date utilizabilă într-un anumit SGBD, cum ar fi MySQL, MariaDB, MS SQL Server sau oricare altul. Să aruncăm o privire la cele mai bune practici pe care să le ținem cont atunci când proiectăm un ERD, astfel încât baza de date rezultată să funcționeze cât mai bine.

Definiți tipul de bază de date de proiectat

De obicei, se disting două tipuri fundamentale de baze de date: relaționale și dimensionale .

Bazele de date relaționale sunt folosite pentru aplicațiile tradiționale care execută tranzacții pe date – adică obțin informații din baza de date, o procesează și stochează rezultatele.

Pe de altă parte, bazele de date dimensionale sunt folosite pentru crearea de depozite de date: depozite mari de informații pentru analiza datelor și data mining pentru a obține informații.

Primul pas în orice sarcină de proiectare a bazei de date este să alegeți unul dintre cele două tipuri principale de baze de date cu care să lucrați: relațional sau dimensional. Este vital să aveți clar acest lucru înainte de a începe să proiectați. În caz contrar, puteți cădea cu ușurință în greșeli de proiectare care vor duce în cele din urmă la multe probleme și vor fi greu (sau imposibil) de corectat.

Adoptarea unei convenții de denumire

Numele folosite în proiectarea bazei de date sunt esențiale deoarece, odată ce un obiect este creat într-o bază de date, schimbarea numelui acestuia poate fi fatală. Schimbarea unei singure litere a numelui poate rupe dependențe, relații și chiar sisteme întregi.

De aceea, este esențial să lucrezi cu o convenție de denumire sănătoasă: un set de reguli care te scutește de problemele de a încerca 50 de posibilități diferite de a găsi numele unui obiect pe care nu-l poți aminti.

Nu există un ghid universal despre ce ar trebui să fie o convenție de denumire pentru a-și face treaba. Dar lucrul important este să stabiliți o convenție de denumire înainte de a numi oricare dintre obiectele dintr-o bază de date și de a menține acea convenție pentru totdeauna. O convenție de denumire stabilește linii directoare, cum ar fi dacă să folosiți un caracter de subliniere pentru a separa cuvintele sau pentru a le uni direct, dacă să folosiți toate literele majuscule sau să scrieți cu majuscule (stil Camel Case), dacă să folosiți cuvinte la plural sau la singular pentru a denumi obiecte și așa mai departe.

Începeți cu designul conceptual, apoi cu designul logic și, în final, cu designul fizic.

Aceasta este ordinea firească a lucrurilor. Ca designer, ați putea fi tentat să începeți prin a crea obiecte direct în DBMS pentru a sări peste pași. Dar acest lucru vă va împiedica să aveți un instrument de discutat cu părțile interesate pentru a vă asigura că designul îndeplinește cerințele de afaceri.

După proiectarea conceptuală, trebuie să treceți la proiectarea logică pentru a avea o documentație adecvată pentru a ajuta programatorii să înțeleagă structura bazei de date. Este vital să păstrați designul logic actualizat pentru a fi independent de motorul bazei de date care va fi utilizat. În acest fel, dacă în cele din urmă migrați baza de date la un alt motor, designul logic va fi în continuare util.

În cele din urmă, designul fizic poate fi creat de către programatori înșiși sau de un DBA, luând designul logic și adăugând toate detaliile de implementare necesare pentru a-l implementa pe un anumit DBMS.

Creați și mențineți un dicționar de date

Chiar dacă un ERD este clar și descriptiv, ar trebui să adăugați un dicționar de date pentru a-l face și mai clar. Dicționarul de date menține coerența și consistența în proiectarea bazei de date, în special atunci când numărul de obiecte din acesta crește semnificativ.

Scopul principal al dicționarului de date este de a menține un singur depozit de informații de referință despre entitățile unui model de date și atributele acestuia. Dicționarul de date ar trebui să conțină numele tuturor entităților, numele tuturor atributelor, formatele și tipurile de date ale acestora și o scurtă descriere a fiecăruia.

Dicționarul de date oferă un ghid clar și concis pentru toate elementele care compun baza de date. Acest lucru evită crearea mai multor obiecte care reprezintă același lucru, ceea ce face dificil să știi la ce obiect să apelezi atunci când trebuie să interoghezi sau să actualizezi informații.

Mențineți criterii consecvente pentru cheile primare

Decizia de a utiliza chei naturale sau chei surogat trebuie să fie consecventă în cadrul unui model de date. Dacă entitățile dintr-un model de date au identificatori unici care pot fi gestionați eficient ca chei primare ale tabelelor respective, nu este nevoie să creați chei surogat.

Dar este obișnuit ca entitățile să fie identificate prin mai multe atribute de diferite tipuri – date, numere și/sau șiruri lungi de caractere – care pot fi ineficiente pentru formarea cheilor primare. În aceste cazuri, este mai bine să creați chei surogat de tip numeric întreg, care oferă eficiență maximă în gestionarea indexului. Și cheia surogat este singura opțiune dacă unei entități îi lipsesc atributele care o identifică în mod unic.

Utilizați tipurile de date corecte pentru fiecare atribut.

Anumite date ne oferă opțiunea de a alege ce tip de date să folosim pentru a le reprezenta. Datele, de exemplu. Putem alege să le stocăm în câmpuri de tip dată, câmpuri de tip dată/ora, câmpuri de tip varchar sau chiar câmpuri de tip numeric. Un alt caz este datele numerice care nu sunt folosite pentru operațiuni matematice, ci pentru a identifica o entitate, cum ar fi un număr de permis de conducere sau un cod poștal.

În cazul datelor, este convenabil să folosiți tipul de date al motorului, ceea ce facilitează manipularea datelor. Dacă trebuie să stocați doar data unui eveniment fără a specifica ora, tipul de date de ales va fi pur și simplu Data; dacă trebuie să stocați data și ora când a avut loc un anumit eveniment, tipul de date ar trebui să fie DateTime.

Utilizarea altor tipuri, cum ar fi varchar sau numeric, pentru a stoca datele poate fi convenabilă, dar numai în cazuri foarte particulare. De exemplu, dacă nu se știe dinainte în ce format va fi exprimată o dată, este convenabil să o stocați ca varchar. Dacă performanța căutării, sortarea sau indexarea sunt esențiale în gestionarea câmpurilor de tip dată, o conversie anterioară în float poate face diferența.

Datele numerice care nu sunt implicate în operații matematice trebuie reprezentate ca varchar, aplicând validări de format în înregistrare pentru a evita inconsecvențele sau repetările. În caz contrar, te expui riscului ca unele date să depășească limitele câmpurilor numerice și te obligă să refactorizezi un design atunci când acesta este deja în producție.

Utilizarea tabelelor de căutare

Unii designeri neexperimentați pot crede că utilizarea excesivă a tabelelor de căutare pentru a normaliza un design poate complica inutil ERD-ul unei baze de date, deoarece adaugă un număr mare de tabele „satelit” care uneori nu au mai mult de o mână de elemente. Cei care cred acest lucru ar trebui să înțeleagă că utilizarea tabelelor de căutare are mult mai multe beneficii decât dezavantaje. Dacă complexitatea sau dimensiunea unui ERD reprezintă o problemă, există instrumente de proiectare ERD care vă permit să vizualizați diagramele în diferite moduri pentru a fi înțelese în ciuda complexității lor.

Acest exemplu de interogare ilustrează utilizarea corectă a tabelelor de căutare într-o bază de date bine concepută:

 SELECT StreetName, StreetNumber, Cities.Name AS City, States.Name AS State FROM Addresses INNER JOIN Cities ON Cities.CityId = Addresses.CityId INNER JOIN States ON States.StateId = Addresses.StateId

În acest caz, folosim tabele de căutare pentru orașe și state.

Beneficiile tabelelor de căutare includ reducerea dimensiunii bazei de date, îmbunătățirea performanței de căutare și impunerea de restricții asupra setului de date valid pe care îl poate conține un câmp, printre altele. De asemenea, este o practică bună ca toate tabelele de căutare să includă un câmp Bit sau Boolean care indică dacă o înregistrare din tabel este în uz sau este învechită. Acest câmp poate fi folosit ca filtru pentru a evita elementele învechite ca opțiuni în interfața de utilizare a aplicației.

Normalizați sau denormalizați în funcție de tipul bazei de date

În bazele de date relaționale utilizate pentru aplicațiile tradiționale, normalizarea este o necesitate. Este bine cunoscut faptul că normalizarea reduce spațiul de stocare necesar prin evitarea redundanțelor. Îmbunătățește calitatea informațiilor și oferă mai multe instrumente pentru a optimiza performanța în interogările complexe.

Cu toate acestea, în alte tipuri de baze de date, se aplică o tehnică cunoscută sub numele de denormalizare. În bazele de date dimensionale, folosite ca depozite de date, denormalizarea adaugă anumite informații redundante utile în tabelele de schemă.

Deși par a fi concepte opuse, denormalizarea nu înseamnă anularea normalizării. Este de fapt o tehnică de optimizare aplicată unui model de date după normalizarea acestuia pentru a simplifica scrierea și raportarea interogărilor.

Proiectarea modelelor fizice pe piese

Într-un proiect de dezvoltare software, proiectantul bazei de date prezintă părților interesate un model conceptual la scară largă, în care nu sunt afișate detalii de implementare. La rândul său, pentru a lucra cu dezvoltatorii, designerul trebuie să ofere un model fizic cu toate detaliile fiecărei entități și atribute. Cu toate acestea, ambele modele nu trebuie să fie create complet la începutul proiectului.

Atunci când aplică metodologii agile, fiecare dezvoltator de la începutul fiecărui ciclu de dezvoltare ia una sau mai multe povești de utilizator pentru a lucra în timpul acelui ciclu. Sarcina designerului bazei de date este de a oferi fiecărui dezvoltator un submodel fizic care include doar obiectele de care au nevoie pentru o unitate de lucru.

La sfârșitul fiecărui ciclu de dezvoltare, submodelele create în timpul acelui ciclu sunt îmbinate astfel încât modelul fizic complet să ia contur paralel cu dezvoltarea aplicației.

Folosirea corectă a vizualizărilor și indexurilor

Vizualizările și indexurile sunt două instrumente fundamentale în proiectarea bazelor de date pentru a îmbunătăți performanța aplicației. Utilizarea vizualizărilor permite gestionarea abstracțiilor care simplifică interogările, ascunzând detaliile inutile ale tabelului. La rândul lor, vizualizările fac sarcinile de optimizare a interogărilor mai ușoare pentru motoarele de baze de date, deoarece le permit să anticipeze modul în care vor fi obținute datele și să aleagă cele mai bune strategii pentru a furniza mai rapid rezultatele interogărilor.

Indecșii pot îmbunătăți performanța unei interogări lente pe baza experienței utilizatorului odată ce baza de date este în producție. Cu toate acestea, crearea indexului se poate face ca parte a sarcinilor de proiectare a bazei de date, anticipând nevoile aplicației.

Pentru crearea de indici, trebuie să aveți o idee aproximativă a mărimii fiecărui tabel – în termeni de număr de înregistrări – și apoi să creați indici pentru tabelele mai mari. Pentru a alege câmpurile de inclus într-un index, trebuie să luați în considerare în principal cele reprezentând chei străine și cele care vor fi folosite ca filtre în căutări.

Când crezi că lucrarea este terminată, este timpul să refactorezi.

Designul unei baze de date poate fi întotdeauna îmbunătățit. Atunci când nu există modificări ale bazei de date din cauza noilor cerințe sau a noilor nevoi de afaceri, este o bună oportunitate de a efectua proceduri de refactorizare care îmbunătățesc proiectarea. Refactorizarea înseamnă pur și simplu că: introducerea unor modificări care îmbunătățesc un design fără a afecta semantica bazei de date.

Există multe tehnici de refactorizare pentru îmbunătățirea designului unei baze de date care intră în afara domeniului acestui articol, dar este bine să știți de existența lor pentru a le folosi atunci când este necesar.

Având la îndemână această listă de bune practici ori de câte ori trebuie să proiectați o bază de date, vă va permite să obțineți cele mai bune rezultate, astfel încât aplicațiile să mențină întotdeauna performanțe optime în accesul la date.