PROGRAMUL DE STUDIU MANAGEMENT ÎN TEHNOLOGIA INFORMAȚIEI FORMA DE ÎNVĂȚĂMÂNT CU FRECVENȚĂ Disertație COORDONATOR ȘTIINȚIFIC PROF. DR. ING. CORNELIA… [609628]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU MANAGEMENT ÎN
TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT CU FRECVENȚĂ

Disertație

COORDONATOR ȘTIINȚIFIC
PROF. DR. ING. CORNELIA AURORA GYŐRÖ DI

ABSOLVENT: [anonimizat]
2020

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU CALCULATOARE
FORMA DE ÎNVĂȚĂMÂNT CU FRECVENȚĂ

Integrarea și analiza
performanț ei mai multor baze de
date în Symfony cu Doctrine

COORDONATOR ȘTIINȚIFIC
PROF. DR. ING. CORNELIA AURORA GYŐRÖDI

ABSOLVENT: [anonimizat]
2020

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI
DEPARTAMENTUL CALCULATO ARE ȘI TEHNOLOGIA INFORMAȚIEI

TEMA

Lucrare de finalizare a studiilor a student: [anonimizat]: CHILBA CRISTIAN

1) Tema lucrării de finalizare a studiilor:
INTEGRAREA ȘI ANALIZA PERFORMANȚEI MAI MULTOR BAZE DE DATE ÎN
SYMFONY CU DOCTRINE

2) Termenul pentru preda rea lucrării: 26 iunie 2020

3) Elemente inițiale pentru elaborarea lucr ării de finalizare a studiilor: framework -ul
Symfony și documentația acestuia , limbajul de bază PHP, bazele de date implementate

4) Conținutul lucrării de finalizare a studiilor: INTR ODUCERE ; TEHNOLOGII
UTILIZATE – PHP7, Symfony , Composer, Git & Bitbucket , MySQL & MariaDB Server,
SQLite, PostgreSQL, PHPStorm ; METODA DE IMPLEMENTARE – Structura bazei de date ,
Componente Symfony și concepte OOP ; ANALIZA DE PERFORMANȚĂ – Configurația
sistemului, Testarea MySQL (MariaDB Server), Testarea PostgreSQL, Testarea SQLite ,
Sinteza rezultatelor ; CONCLUZII ; BIBLIOGRAFIE .

5) Material grafic: diverse scheme și figuri , capturi de ecran.

6) Locul de documentare pentru elaborarea lucrării: Internet, biblioteca universității

7) Data emiterii temei: 02 octombrie 2 019

Coordonator științific
Prof. dr. ing. Cornelia Aurora GYŐRÖDI

1
CUPRINS

INTRODUCERE ………………………….. ………………………….. ………………………….. …………………. 2
Capitolul I. TEHNOLOGII UTILIZATE ………………………….. ………………………….. ………….. 4
I.1 PHP7 ………………………….. ………………………….. ………………………….. ………………………….. . 4
I.2 Symfony ………………………….. ………………………….. ………………………….. ………………………. 5
I.3 Composer ………………………….. ………………………….. ………………………….. …………………….. 7
I.4 Git & Bitbucket ………………………….. ………………………….. ………………………….. …………… 8
I.5 Mysql & MariaDB Server ………………………….. ………………………….. ………………………….. . 9
I.6 SQLite ………………………….. ………………………….. ………………………….. ………………………. 11
I.7 PostgreSQL ………………………….. ………………………….. ………………………….. ………………… 14
I.8 PHPStorm ………………………….. ………………………….. ………………………….. …………………. 16
Capitolul II. Metoda de implementare ………………………….. ………………………….. …………….. 18
II.1 Structura bazei de date ………………………….. ………………………….. ………………………….. … 18
II.2 Componente Symfony și concepte OOP ………………………….. ………………………….. ……. 19
Capitolul III. Analiza de performan ță ………………………….. ………………………….. …………….. 28
III.1 Configurația sistemului ………………………….. ………………………….. ………………………….. 33
III.2 Testarea MySQL (MariaDB Server) ………………………….. ………………………….. ………… 34
III.3 Testarea Postg reSQL ………………………….. ………………………….. ………………………….. …. 34
III.4 Testarea SQLite ………………………….. ………………………….. ………………………….. ………… 35
III.5 Sinteza rezultatelor ………………………….. ………………………….. ………………………….. ……. 36
CONCLUZII ………………………….. ………………………….. ………………………….. ……………………… 38
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ……………….. 40

2
INTRODUCERE

Scopul prezentei lucrări este de a analiza modul de implementare și de a testa
performanța mai multor tipuri de baze de date integrate cu Doctrine în Symfony, unul dintre
cele mai populare și apreciate framework -uri PHP din prezent axate pe domeniul dezvol tării
web.
În cea mai mare parte din cazuri, aplicațiile web sau website -urile construite cu Symfony
nu sunt construite pentru a îndeplini cerințe business foarte complexe, ceea ce duce la concluzia
folosirii unei singure baze de date pentru respectivele proiecte. În ciuda acestui fapt, Symfony
permite integrarea și folosirea concomitentă a mai multor tipuri de baze de date în cadrul unui
singur proiect, pentru acele cazuri în care se dorește acest lucru.
Această lucrare iși propune să studieze modul în c are acest lucru poate fi realizat, cât și
să ruleze o serie de teste de performanță pe diferitele implementări, simulând într -un mod cât
mai apropiat de cazurile reale diferite operații executate pe seturi mari de date.
Motivul alegerii temei a fost , în primul rând , curiozitatea proprie, iar mai apoi luarea în
considerare a posibilității îmbogățirii cunoștințelor proprii în ceea ce privește domeniul
dezvoltării web, domeniu în care activez la momentul prezent . De asemenea, această lucrare ar
putea fi și un eventual punct de plecare pentru alegerea soluțiilor de baze de date potrivite pentru
viitoarele proiecte.
Așadar, acest studiu își va găși utilitate în rândul persoanelor care doresc să aprofundeze
cunoștințele în domeniul dezvoltării web, care utilize ază Symfony drept framework pentru
diversele proiecte dezvoltate, a celor interesați de a găsi soluția potrivită de stocare de date, în
funcție de cerințele date , și chiar celor care doresc să afle mai multe despre cele mai actuale
tehnologii din acest dom eniu, care stau la baza implementării propuse .
Bazele de date alese pentru acest proiect sunt MariaDB, PostgreSQL și SQLite. Toate
bazele de date vor avea aceeași structură, iar ope rațiile rulate vor fi INSERT, SELECT și
DELETE, în această ordine. Indicii de performanță urmăriți vor fi atât timpul de execuție, cât
și memoria consumată.

3
Pentru a nu devia foarte mult de la subiectul propus, implementarea propusă va fi cât
mai succintă. Bazele de date folosite pentru testare vor avea o structură simplă – se va stoca un
număr mic de câmpuri pentru fiecare tabel.
Toate testele se vor realiza în două contexte diferite, ceea ce va duce la două variante
de structuri pentru tabelele bazelor de date :
 Primul caz va folosi un singur ta bel, fără niciun fel de relații, pe care se vor efectua
100.000 de iterații din fiecare tip de operație mai sus menționată
 În al doilea caz se vor folosi două entități, așadar două tabele, într -o relație având
cardinalitatea One-To-Many . În acest caz, se vor executa 90.000 de iterații pe fiecare
dintre operațiile enunțate (30.000 pe entitățile principale, fiecare având câte 3
entități referite)
Implementarea aplicației a avut la bază Symfony 5, ultima variantă majoră a acestui
framework. Deoarece limbajul de bază este PHP, ca mediu de de zvoltare a fost utilizat
PHPStorm.
Capitolul I, TEHNOLOGII UTILIZATE, va urm ări să prezinte o scurtă sinteză despre
tehnologiile și conceptele utiliza te în implementarea propusă .
În capitolul II, intitulat METODA DE IMPLEMENTARE , se vor urmări date teh nice
cu privire la implementarea bazei de date, se vor analiza câteva dintre funcțiile de bază utilizate
pentru testare, respectiv câteva componente și concepte Symfony importante pentru contextul
dat.
Capitolul III , ANALIZA DE PERFORMANȚĂ va prezenta rezultatul testelor rulate,
arătând atât rezultate medii obținute, cât și re zultatele pe fiecare iterație , iar ultimul capitol va
fi cel de CONCLUZII , în care se vor interpreta aceste rezultate .

4
Capitolul I. TEHNOLOGII UTILIZATE

I.1 PHP7
PHP, acronim recursiv pen tru PHP: Hypertext Preprocessor este un limbaj de scriptare
open source cu scop general, utilizat pe scară largă, potrivit în mod special pentru dezvoltarea
aplicațiilor web și care poate fi inclus în pagini HTML [1].

Figura I.1: Sintaxa unei comenzi PHP [2]

În Figura I.1 [2] se poate observa structura unei simple comenzi PHP, care poate fi
inclusă oriunde într -o pagină HTML pentru a afișa șirul de caractere “Hell o World…”.
Spre deosebire de JavaScript, codul PHP este executat pe parte de server, generând cod
HTML care este apoi trimis clientului. Astfel, clientul (browserul), va primi rezultatul scriptului
PHP, dar nu va ști ce cod s -a rulat. PHP poate fi astf el folosit ca modalitate de procesare a
fișierelor HTML, adică drept motor de templating [1].
PHP poate fi folosit pe toate sistemele de operare majore, incluzând Linux, multe
varia nte de Unix, Microsoft Windows și macOS . De asemenea, PHP suportă majorita tea
tipurilor de server web din ziua de azi, cum ar fi Apache, IIS1 și nginx [1].
O altă caracteristică importantă a PHP este faptul c ă funcționează cu o arie la rgă de baze
de date, oferind suport pentru extensii specifice pentru o anumită bază de date și chiar straturi
de abstractizare precum PDO ( PHP Data Objects ).

1 IIS – Internet Information Services, web server creat de Microsoft

5
Versiunea 7 a limbajului a venit cu un număr semnificativ de îmbună tățiri, cum ar fi o
viteză de răspuns aproape dublă față de versiunea anterioară, implementarea declarațiilor de tip
pentru variabile, noi tehnici de manipulare a erorilor, noi operatori și chiar și funcții pentru
generarea de numere pseudo -aleatorii sigure din punct de vedere criptografic.
În aplicația dată, PHP a reprezentat probabil cea mai importantă tehnologie, fiind
limbajul pe care se bazează Symfony , framework -ul PHP folosit și fiind tehnologia responsabilă
pentru cea mai mare parte a procesării și transmiterii de date.

I.2 Symfony
Potrivit site -ului oficial, Symfony este „un set de componente PHP, un cadru de apl icații
web, o filozofie și o comunitate – toate lucrând împreună în armonie” [3]. Urmând conceptul
de a începe mic și de a adăuga mai multe funcționalități după cum este necesar, conceptul
permite utilizarea componentelor prezentate împreună, pentru o expe riență completă Symfony ,
sau decuplat – în funcție de necesitățile proiectului PHP.
Datorită arhitecturii sale bazate pe componente, Symfony Framework este extrem de
modular și versatil. Având în vedere că aceste componente sunt construite pentru a putea fi
reutilizabile și de sine stătătoare, dezvoltatorii pot alege dintre peste 50 de componente
Symfony pe baza nevoilor lor specifice . Sarcini repetitive, dar complexe, cum ar fi generarea
de adrese URL, construcția de formulare , scrierea diferitelo r coduri de depanare sau
implementarea unui sistem de memorie în cache, pot fi, prin urmare, incluse rapid în aplicație
prin instalarea componentelor necesare cu ajutorul Composer.
Arhitectura Symfony este ilustrată în Figura I.1, care va prezenta o diagramă a unei
aplicații Symfony, atât în cazul modului de dezvoltare, cât și în cel al producției . Schema va
prezenta diferitele componente care alcătuiesc sistemul din punct de vedere software, respectiv
modul în care acestea sunt i nterconectate și realizează schimburi de date .

6

Figura I.2: Symfony 5 – Schema Arhitecturii Software [4]

De asemenea, acest framework implementează mai multe standarde PHP -FIG, precum
cele pentru stilu l codului (PSR -2), interfața logger și standardele interfeței de caching (PSR -3
și PSR -6), autoloader (PSR -4) și container service (PSR -11). Avantajul implementării acestor
standarde este că permite o interoperabilitate ușoară cu alte biblioteci. [5]
De asemenea, este foarte personalizabil, permițând dezvoltatorilor să folosească sistemul lor
de baze de date preferat ( având posibilitatea de a folosi atât baze de date relaționale, cât și non –
relaționale), aceeași flexibilitate aplicându -se și pentru sis temul ORM , motor ul de șabloane și
chiar și metoda de construire a configurațiilor (adnotări, YAML, XML și PHP).
Legarea sistemului persistent la cadrul Symfony se face folosind conceptul de ORM2
Deoarece bazele de date sunt în mare parte relaționale, iar Symfony este orientată către obiect,
o interfață este utilizată pentru a transpune logica obiectului în logica relațională. Acest strat de

2 ORM ( Object -Relational Mapping ) – tehnic ă de programare pentru convertirea datelor între sisteme
incompatibile , folos ind limbaje de programare orientate pe obiecte

7
abstractizare împiedică nevoia dezvoltatorilor de a scrie sintaxă specifică unui anumit sistem
de bază de date , ajut ând deci la versatilitatea Symfony. [ 6]

I.3 Composer
Composer este o util itară folosită pentru managemen tul dependințelor în PHP. Permite
specificarea librăriilor de care depinde proiectul PHP, iar utilitara le va man ageria
(instala/ actualiza ) în mod aut omat prin rularea unei simple comenzi [7].
Chiar dacă funcționează cu pachete, Composer nu este un manager de pachete precum
Yum sau Apt în contextul Linux. Composer lucrează cu pachete, sau librării, dar le gestionează
pe bază de proiect, și nu le instal ează global doar dacă se specifică asta.
Composer este util în următorul context [7]:
 Avem un proiect care depinde de un număr de librării
 Unele dintre aceste librării depind, la rândul lor, de alte librării
În acest caz, Composer :
 Permite declararea librăriilor de care depinde proiectul
 Găsește ce versiuni ale căror pachete pot fi instalate și trebuie instalate, le
descarcă într-un folder al proiectului (de obicei numit vendor ) alături de restul
librăriilor de care depind, în mod recursiv

Specificaț iile cu privire la dependințe sunt declarate într -un fișier de tip JSON, numit
composer.json și inclus în proiect. Astfel, se vor putea declara dependințele în format JSON,
într-o cheie de obiect numită require , alături de alte metadate, cum ar fi numele p achetului sau
al proiectului , proprietarul, date cu privire la licență, etc.
În Figura I.3 se pot observa primele linii ale fișierului composer.json al proiectului
Symfony implementat pentru această lucrare . Pe lângă metadatele cu privire la tipul aplicației
și al licenței folosite, se pot observa niște declarații de librării de care depinde framework -ul.

8

Figura I.3: Fragment de fișier composer.json

Composer a fost folosit toc mai cu a cest scop în aplicația curentă , fiind benefic în ceea
ce privește portabilitatea și modularitatea . Symfony se axează de asemenea în foarte mare parte
pe d iferitele componente care intră în alcătuirea sa , iar instalarea lor se face folosind în
exclu sivitate Composer.

I.4 Git & Bitbucket
Git este un VCS ( Version Control System ), adică un sistem pentru controlul versiunilor
care permite urmărirea schimbărilor realizate pe fișiere. Folosind Git, este posibil să revenim la
versiuni anterioare ale unor fișiere, să restaurăm fișiere șterse sau chiar să găsim unde a fost
introdusă o anumită linie de cod [8].
Modul de funcționare Git este de a crea un folder . git care va stoca detalii cu privire la
sistemul de fișiere și va iniția astfel un așa numit repository de Git. Git urmărește schimbările
fișierelor după ce utilizator ul creează un “punct de salvare” numit commit . Fiecare commit
stochează doar schimbările cauzate asupra fișierelor de la ultimul commit , ceea ce p ermite
extragerea unui commit fă ră a fi nevoie de întreaga sa istorie [8].
Git are mai multe avantaje, fiind util atât pentru proiecte mici, în special pentru
portabilitate, dar și pentru siguranța datelor (salvarea unui repository pe Git reprezintă o
modalitate eficientă de a stoca o copie de rezervă, un backup) , dar și pentru proiecte mari. În

9
acest sens, Git oferă posibilitat ea creării de branch -uri, ceea ce permite ca mai mulți
dezvoltatori să lucreze pe copii independente ale acelorași fișiere, fără a interfera unul cu alt ul
și, dacă toți r espectă un anumit flux de lucru, fără conflicte.
Deoarece în cazul acestui proiect am fost singurul dezvoltator, Git a fost folosit în
special pentru portabilitate, permițându -mi, alături de composer, să lucrez pe mai multe
dispozitive și să fiu mereu la curent cu ultima versiune a aplicației rapid, prin introducerea unor
simple comenzi.
Bitbucket este un serviciu de găzduire pentru repository -uri de sisteme de control al
versiunilor , deținut de Atlassian, pentru proiecte care utilizează Mercurial sau Gi t pentru
controlul versiunilor. În Figura I.4 se poate observa o parte din interfața Bitbucket, care oferă
posibilitatea de a vedea în mod clar și plăcut vizual commit -urile din cadrul proiectului.

Figura I.4: Interfața web Bitbucket pentru lista de commit -uri

I.5 Mysql & MariaDB Server
O bază de date este, în sensul cel mai general, o colecție organizată de date [9]. Se pot
găsi baze de date atât în format fizic, cum ar fi un cat alog școlar, cât și în format electronic.
Mai specific, în ceea ce privește domeniul electronic, o bază de date poate fi considerată
un sistem electronic ce permite ca datele să fie accesate, manipulate și actualizate cu ușurință
[9]. De obicei, proiecta nții de baze de date, fie ele fizice sau electronice, încearcă să organizeze
datele într -o maniera care să corespundă anumitor aspecte din viața reală, ceea ce face date le
mai ușor de accesat, atâ t de către diferite le procese cât și de către om.

10
Dacă pri mele baze de date erau plate, adică erau limitate strict la rânduri și coloane
(similar unei foi de calcul), cele moderne sunt organizate în funcție de relațiile dintre diferitele
tipuri de date. Acestea se numesc baze de date relaționale, sunt structurate în tabele, rânduri și
coloane și sunt indexate, ceea ce permite găsirea informațiilor relevante mai rapid și mai ușor.
MySQL este probabil cel mai popular sistem open -source3 de management al bazelor
de date relaționale, fiind dezvoltat și distribuit de Oracle Corporation. Astfel, pentru a accesa și
procesa date existente într -o bază de date, este necesar un sistem de management al bazelor de
date precum MySQL Serv er [10].
SQL ( Structured Query Language ) reprezintă cel mai c omun limbaj standardizat pen tru
accesul la baze de date. În funcție de necesități, SQL poate fi introdus în mod direct, de exemplu
pentru a genera rapoarte, poate fi inclus în cod scris în alte limbaje de programare pentru a
executa funcționalități mai complexe, sau poate fi folosit alături de un API4 specific pentru un
anumit limbaj, astfel î ncât sintaxa SQL să fie ascunsă [10].
Cele patru funcții de bază pentru depozitare permanentă executate cu baze de date sunt
operațiile CRUD ( Create, Read, Update, Delete ), pentru care SQL furni zează câte un statement
(declarație, funcție).
MariaDB Server este unul dintre cele mai populare servere de baze de date din lume.
Este realizat de dezvoltatorii originali ai MySQL și este garantat să rămână open source.
Utilizatorii notabili includ Wiki pedia, WordPress.com și Google. [20]
MariaDB transformă datele în informații structurate într -o gamă largă de aplicații, de la
servicii bancare la site -uri web. Proiectat inițial ca înlocuitor îmbunătățit, drop -in pentru
MySQL, MariaDB este utilizat pentru că este rapid, scalabil și robust, cu un ecosistem bogat de
motoare de stocare, plugin -uri și multe alte instrumente îl fac foarte versatil pentru o mare
varietate de cazuri de utilizare. [20]

3 Open -source – reprezintă software al cărui cod sursă a fost făcut disponibil gratuit, putând fi redistribuit sau
modificat după nevoile proprii
4 API – Application Programming Interface – set de metode defin it pentru comunicarea între diferite componente
software

11
MariaDB este dezvo ltat ca software open source și, ca bază de date relațională, oferă o
interfață SQL pentru accesarea datelor . Ultimele versiuni ale MariaDB includ, de asemenea,
caracteristici GIS5 și JSON6. [20]

I.6 SQLite
SQLite este o bibliotecă in -process (nu necesită un proces server separat) care
implementeaz ă un motor de bază de date SQL tranzacționa l de sine stătător, fără server, cu
configurație zero . Codul pentru SQLite se află în domeniul public și este astfel gratuit pentru
utilizare în orice scop, fie el comercial sau privat. SQLite este cea mai extinsă bază de date din
lume, fiind utilizată inclusiv în cadrul mai multor proiecte cu profil înalt. [11]
SQLite este o bază de date încorporată. Spre deosebire de majoritatea bazelor de date
SQL, SQLite nu are un proces de server separat. SQLite citește și scr ie direct pe fișier e obișnuite
stocate pe disc. O bază de date SQL completă cu mai multe tabele, indici, declanșatori și
vizualizări este conținută într -un singur fișier de disc. Formatul fișierului bazei de date este
multi -platform – se pot copia în mod l iber baze de date între sistemele pe 32 de biți și pe 64 de
biți sau între arhitecturile de tip big -endian și little endian. Aceste caracteristici fac din SQLite
o alegere populară ca un Application File Format7. [11]
SQLite este o bibliotecă compactă. Cu toate caracteristicile activate, dimensiunea
bibliotecii poate fi mai mică de 600 KB, în funcție de platforma țintă și setările de optimizare a
compilatorului. Există un compromis între utilizarea memoriei și viteză. În general, SQLite
rulează mai rapid c u cât mai multă memorie i se alocă . Cu toate acestea, performanțele sunt de
obicei destul de bune chiar și în medii cu memorie redusă. În funcție de modul în care este
utilizat, SQLite poate fi mai rapid decât sistem ul de fișiere . [11]
În loc să ruleze ind ependent ca un proces autonom, acesta coexistă simbiotic în
interiorul aplicației pe care o servește – în spațiul procesului său. Pentru un observator extern,

5 GIS – Geographic Information System – sistem informatic utilizat pentru manipularea datelor referitoare la pozi ții
de pe suprafața Pământului
6 JSON – JavaScript Object Notation – format de schimb de date care folosește text ușor de interpretat de către
om pentru a stoca și transmite date structurate în obiecte
7 Application File Format – formatul de fișier utilizat pentru a persista starea aplicației pe disc sau pentru a schimba
informații între pr ograme

12
nu ar fi niciodată evident că un astfel de program poate avea la bord un sistem relațional de
gestionare a bazelor de date (RDBMS). Programul își va face treaba și își va gestiona datele
într-un mod silențios . Totuși, în interior, există un motor de bază de date complet, de sine
stătător, în lucru. [12]
De fiecare dată când comparăm SQLite cu alte mot oare de baze de date SQL cum ar fi
SQL Server, PostgreSQL, MySQL sau Oracle, este important să ne dăm seama în primul rând
că SQLite nu este destinat ca un înlocuitor sau concurent la niciunul dintre aceste sisteme.
SQLite este fără server. Nu există un pr oces de server separat care să gestioneze baza de date.
O aplicație interacționează cu motorul bazei de date folosind apeluri funcționale, nu trimi țând
mesaje către un proces sau thread separat.
O bază de date SQLite este un singur fișier de disc obișnuit care poate fi localizat
oriunde în ierarhia de directoare. Dacă SQLite poate citi fișierul pe disc, poate citi orice din
baza de date. Dacă fișierul de disc și directorul său pot fi scrise, atunci SQLite poate schimba
orice din baza de date. Fișierele baze i de date pot fi ușor copiate pe un stick de memorie USB
sau trimise prin e -mail pentru partajare.

Figura I.5: SQLite încorporat în procese host [12]

13
Motoarele de baze de date SQL client / server se străd uiesc să implementeze un depozit
partajat de date de tip enterprise . Ele subliniază scalabilitatea, concuren ța, centralizarea și
controlul. SQLite se străduiește să ofere stocare locală de date pentru aplicații și dispozitive
individuale. SQLite pune accen t pe economie, eficiență, fiabilitate, independență și simplitate ,
urmând arhitectura prezentată în Figura I.5.
Așadar, în ceea ce privește situațiile în care SQLite ar putea fi o alegere bună se pot
menționa: [13]
 Dispozitive de t ip embedded și domeniul IoT: Datorită faptului că SQLite nu
necesită administrare, este recomandat pentru dispozitive care nu necesită suport
tehnic expert, cum ar fi acele dispozitive de zi cu zi care se conectează la internet
și realizează schimburi de d ate
 Website -uri cu trafic mic și mediu
 Domeniul analizei de date: Utilizând interfața command -line sqlite3, se pot
analiza seturi mari de date, importate cu ușurință din fișiere .csv
 Sistem de caching conectat la un sistem de baze de date relaționale de ti p
enterprise: Aceast ă metodă reduce latența sistemului , deoarece majoritatea
interogărilor apar acum în cache -ul local și evită transferul prin network . De
asemenea, reduce încărcarea în rețea și pe serverul de bază de date central. Și în
multe cazuri, îns eamnă că aplicația din partea clientului poate continua să
funcționeze în timpul întreruperilor din rețea
 Format de transfer de date : Deoarece o bază de date SQLite este un singur fișier
compact într -un format bine definit de platformă, este adesea folosit ca un
container pentru transferul de conținut de la un sistem la altul
 Arhiva de fișiere și/sau container de date: SQLite este o soluție bună pentru orice
situație care necesită înglobarea de conținut divers într -un pachet conținut și
auto-descris pentru expediere prin rețea , fiind astfel un potențial substitut pentru
arhive de tip ZIP sau Tarballs8
 Înlocuitor pentru fișiere de date ad -hoc: Multe programe folosesc fopen(),
fread() și fwrite() pentru a crea și gestiona fișiere de date în formate proprii .

8 Tarball – un termen jargon pentru o arhivă TAR – un grup de fișiere colectate împreună ca unul. Termenul
sugerează o bilă de gudron, derivatul de cărbune lipicios folosit ca aderent și sigilant

14
SQLite funcționează deosebit de bine ca înlocuitor pentru aceste fișiere de date
ad-hoc. Contrar intuiție i, SQLite poate fi mai rapid decât sistemul de fișiere
pentru citirea și scrierea conținutului pe disc
 Înlocuitor pentru o bază de date enterprise în tim pul demo -urilor sau testării :
Aplicațiile client utilizează de obicei o interfață de bază de date generică care
permite conexiunile la diverse motoare de baze de date SQL. Este bine să
includeți SQLite în combinația de baze de date acceptate și să legați s tatic
motorul SQLite cu clientul. Astfel, programul client poate fi utilizat autonom cu
un fișier de date SQLite pentru testare sau demonstrații

I.7 Postgre SQL
PostgreSQL este un sistem de baze de date relațional de obiecte puternic, open source,
cu pes te 30 de ani de dezvoltare activă, care și-a câștigat o reputație puternică pentru fiabilitate,
robuste țea caracteristicilor și performanț a deosebit ă.
Originile PostgreSQL datează din 1986 ca parte a proiectului POSTGRES de la
Universitatea California din Berkeley și are mai mult de 30 de ani de dezvoltare activă pe
platforma de bază .
Similar cu cazurile anterioare, d atorit ă licenței de tip open -source , PostgreSQL poate fi
utilizat, modificat și distribuit gratuit de către oricine pentru orice scop, fie c ă este privat,
comercial sau academic.
PostgreSQL a câștigat o reputație puternică pentru arhitectura dovedită, fiabilitatea,
integritatea datelor, setul de caracteristici robust, extensibilitatea și dedicarea comunității open
source din spatele software -ului pentru a oferi soluții performante și inovatoare. PostgreSQL
rulează pe toate sistemele de operare majore, respectă ACID9 din 2001 și are add-on-uri
puternice, cum ar fi extenderul popular al bazelor de date geospatiale PostGIS. Nu este de
mirare că P ostgreSQL a devenit baza de date relațională open source la alegere pentru multe
persoane și organizații. [14]

9 ACID – În domeniul informaticii, ACID (atomicitate, consistență, izolare, durabilitate) este un set de proprietăți
ale tranzacțiilor cu baze de date destinate să garanteze validitatea chiar și în caz de erori, întreruperi de curent etc.

15
PostgreSQL este un descendent open -source al acestui cod original Berkeley. Suporta o
mare parte din standardul SQL și oferă multe funcții mod erne: [15]
 interogări complexe
 chei externe
 declanșatoare
 vizualizări actualizabile
 integritatea tranzacțională
 controlul concurentei multiversionale

De asemenea, PostgreSQL poate fi extins de către utilizator în mai multe moduri, de
exemplu prin adăugar ea de noi : [15]
 tipuri de date
 funcții
 operatorii
 funcții agregate
 metode de index
 limbaje procedurale

În ceea ce privește arhitectura, PostgreSQL folosește un model client / server. O sesiune
PostgreSQL se bazează pe cooperarea următoarelor procese:
 Un proces de server, care gestionează fișierele bazei de date, acceptă conexiuni la baza
de date de la client aplicații și efectuează acțiuni în baza de date în numele clienților.
Programul serverului de baze de date se numește postgres.
 Aplicația client (fr ontend) a utilizatorului care dorește să efectueze operațiuni în baza
de date. Aplicațiile client pot avea o natură foarte diversă: un client ar putea fi un
instrument orientat pe text, o aplicație grafică , un server web care accesează baza de
date pentru a afișa pagini web sau pe chiar un instrument pentru mentenanța bazei de
date

16

Figura I.6: Arhitectura PostgreSQL [16]

În Figura I.6, se pot vedea mai mulți clienți care se cone ctează la server printr -o rețea.
Pentru PostgreSQL, aceasta este o rețea de tip TCP/IP10, o rețea locală (LAN) sau posibil chiar
internet. Fiecare client se conectează la procesul principal de server al bazei de date (prezentat
ca postmaster ), care creează un nou proces server special pentru deservirea cererilor de acces
pentru acel client specific.

I.8 PHPStorm
PHPStorm este un IDE ( Integrated Development Editor ) dedicat limbajului PHP,
dezvoltat de firma JetBrains. Suportă versiuni PHP mai noi dec ât versiunea 5.3 și este construit
având la bază platforma open -source IntelliJ, la care cei de la JetB rains lucrează de mai mult
de 15 ani [19].
IDE-ul furnizează asistență dezvoltării web prin caracteristici precum: sugestii
inteligente de completare a codul ui, evidențierea elementelor de sintaxă, formatare
configurabilă a codului în funcție de anumite standarde, posibilitatea de pliere a codului și multe
altele. De asemenea, oferă posibilitatea efectuării unor refactorizări automate c are vor trata cu

10 TCP/IP ( Transmission Contro l Protocol / Internet Protocol) – este o suită de protocoale de comunicare utilizate
pentru interconectarea dispozitivelor de rețea de pe internet

17
atenție codul și vor permite monitorizarea schimbărilor și confirmarea acestora de către
dezvoltator [19].
Inspecțiile integrate (Code Inspections ) verifică codul pe măsură ce dezvoltatorul
tastează, inspectând întreg proiectul pentru posibile erori. În cazul în care se găsește o eroare
printr -o inspecție, se oferă așa -numitele corecții rapide pentru remedierea sau îmbunătățirea
codului cu ușurință.
Un alt avantaj al acestui IDE este modalitatea eficientă de a naviga prin cod, în special
în cazul proiectelor ma ri, prin posibilitatea de a “sări” printr -un singur click la implementarea
unei anumite metode, clase sau definiție de variabilă.
PHPStorm nu este un IDE dezvoltat strict pentru PHP, deoarece cei de la JetBrains au
integrat în cadrul său toate caracteris ticile de bază WebStorm (un alt IDE dezvoltat de aceeași
firmă ) cu privire la HTML, JavaScript și CSS. Printre aceste caracteristici se numără: editoare
integrate pentru toate cele trei limbaje, funcționalitatea de Live Edit , care permite observarea
instan tanee în browser a schimbărilor efectuate în cod, fără a fi nevoie de un refresh, tehnologii
de ultim ă generație și multe altele [19].
Alte benefici i pentru utilizatorii PHPStorm sunt reprezentate de utilitarele și asistența
de cod menite pentru lucrul cu baze de date respectiv limbajul SQL. De asemenea, mediul de
dezvoltare include o interfață utilizator inclusă pentru cele mai populare sisteme de control al
versiunilor, cum ar fi Git, Svn, Mercurial și Perforce. Mai mult, diferite task -uri de rutină se p ot
executa direct din IDE datorită suportului pentru Vagrant, Docker, Compo ser și diferite alte
utilitare [19].
Motivul folosirii PHPStorm pentru dezvoltarea aplicației este faptul că, în opinia mea,
este cel mai bun mediu de dezvoltare pentru PHP. Am be neficiat de majoritatea avantajelor
menționate mai sus, utilizând în mod constant integrarea cu Git, funcționalitatea de Live Edit
pentru design, modalitățile de navigare prin cod și inspecția automată a codului.

18
Capitolul II. Metoda de implementare

II.1 Structura bazei de date
Toate testele se vor realiza în două contexte diferite, ceea ce va duce la două variante
de structuri pentru tabelele bazelor de date:
 Primul caz va folosi un singur tabel, fără niciun fel de relații
 În al doilea caz se vor folosi două enti tăți, așadar două tabele, într -o relație având
cardinalitatea One -To-Many
Schema bazei de date în varianta simplă se poate vedea în Figura II.1. Tabelul
migration_versions este adăugat în mod automat de către Symfony pentru a stoc a informațiile
necesare cu privire la stadiul migra țiilor bazei de date .

Figura II.1: Structura bazei de date în varianta simplă

În al doilea context de testare, s -a mers pe o relație de tip One -To-Many în care fiecare
autor va putea avea mai multe articole. În cazul acesta, structura va fi cea din Figura II.2.
Deoarece s -a ales o implementare cât mai succintă și la subiect, se poate observa
faptul că datele stocate în ambele tabele sunt mai degrabă la nivel orientativ, structura acestei
baze de date nefiind proiectată în niciun caz pentru a stoca toate datele necesare unor astfel de
entități într -o situație reală.

19

Figura II.2: Structura bazei de date în varianta One -To-Many

O mențiune importantă ar fi folosirea unei chei străine cu opțiunea cascade delete , ceea
ce presupune faptul că dacă o înregistrare din tabelul părinte este ștersă, atunci înregistrările
corespunzătoare din t abelul copil vor fi șterse automat. Această opțiune este utilă pentru
operațiile de tip DELETE – va fi necesară apelarea lor doar pe entitățile de tip Author .

II.2 Componente Symfony și concepte OOP
Migrațiile bazelor de date sunt o modalitate de a actua liza în siguranță schema bazei de
date atât la niv el local, cât și în producție. Un exemplu de rulare a unei migrații, cât și
informațiile afișate drept output, se găsește în Figura II.3.

Figura II.3: Rularea unui Migration

20
Comanda make:migration verifică de fapt baza noastră de date, analizeaz ă toate
clasele noastre de entități și generează codul SQL necesar pentru actualizarea bazei de date
pentru a se potrivi cu entitățile noastr e.

Figura II.4: Verificarea statusului sistemului de Migrations

În ca drul bazei de date, sistemul de Migrations creează automat o nouă tabelă numită
migration_versions . Apoi , la prima execuție a comenzi i doctrine:migrations:migrate , se va
introduce în această tabelă numărul corespunzător migrației care a fost executată . La o rulare
ulterioară, se vor verifica migrațiile deja prezente în această tabel ă și nu vor mai fi executate.
O comandă utilă pentru a obține o multitudine de date utile cu privire la sistemul de migrații
este doctrine:migrations:status , a cărei rezultat se poate observa în Figura II.4.
DoctrineBundle integrează atât proiectele DBAL cât și ORM Doctrine în aplicaț iile
Symfony. Toate aceste opțiuni sunt configurate sub cheia doctrine din configurația aplicației.

21

Figura II.5: Configurarea Doctrine prestabilită din Symfony

Deoarece majoritatea aplicațiilor Symfony ne cesită o singură bază de date, Symfony
vine cu o configurație prestabilită prezentată în Figura II.5, în care se declară o singură
conexiune la baza de date, respectiv un singur manager de entități mapat în mod automat,
pentru toat e entitățile prezente în folderul /src/Entity.

Figura II.6: Configurarea multiplelor conexiuni

22
În cazul acestei lucrări, se vor configura trei conexiuni, una pentru fiecare tip de bază
de date folosit pen tru testare: mysql , sqlite și postgresql . Pentru fiecare dintre acestea este
importantă configurarea URL -ului către baza de date, securizat prin intermediul environment
variables11, respectiv a versiunii serverului de baza de date folosit. Această configura re se poate
observa în Figura II.6.

Figura II.7: Configurarea multiplilor manageri de entități

11 Environment variable – o variabilă a cărei valoare este setată în afara programului, de obicei prin funcționalitatea
încorporată în sistemul de oper are

23
Datorită cerințelor Symfony în ceea ce privește configurarea multiplilor manageri de
entități, și ținând cont de faptul că pentru relevan ța testelor dorim să folosim aceleași entități
pentru toate tipurile de bază de date, fiecare entitate va fi triplată, existând câte o versiune pentru
fiecare namespace12 folosit . În Figura II.7, aceste namespace -uri sunt indicate de cheia prefix .
Acest lucru va cauza redunda nță inutilă în ceea ce privește arhiectura aplicației. Această
problemă poate fi optimizată cu ușurință în două moduri:
 Moștenire de entități – Va exista o ent itate abstractă, care va fi moștenită de fiecare
dintre cele trei entități folosite pentru definirea multiplilor manageri de entități
 Utilizarea conceptului de Tra it – Declararea fiecărei proprietăți a clasei, alături de
metodele get și set vor fi extrase în clase de tip Trait, care vor fi apoi injectate în fiecare
dintre cele trei entități
În cazul de față, am preferat a doua metodă, deoarece consider că este benefică posibilitatea
de a vedea în mod clar ce câmpuri va conține fiecare entitate fără a fi nev oie să analizezi clasa
părinte a acesteia.
Trait -urile sunt un mecanism pentru reutilizarea codului în limbaje moștenire unice,
cum ar fi PHP. O trăsătură este destinată să reducă unele limitări ale moștenirii unice, permițând
unui dezvoltator să refolose ască seturi de metode în mod liber în mai multe clase independente
care trăiesc în ierarhii de clase diferite. Semantica combinației de Trăsături și clase este definită
într-un mod care reduce complexitatea și evită problemele tipice asociate moștenirii mu ltiple și
Mixin -urilor13. [1]
Un Trait este similar unei clase, dar este destinat doar grupării funcționalității într -un mod
precis și consistent. Este imposibilă instanțierea unui Trait . Este un plus la moștenirea
tradițională și permite compoziția orizont ală a comportamentului; adică aplicarea membrilor
clasei fără a necesita moștenir e.
Așadar, entitățile folosite în aplicație vor avea un conținut clar si succint, fiind o înșiruire a
trăsăturilor (în acest caz identice) din care sunt compuse, așa cum se po ate observa în Figura
II.8.

12 Namespace – concept care oferă o modalitate de a grupa clase, interfețe, funcții și constante conexe
13 Mixin – un concept de limbaj care permite unui programator să injecteze un cod într -o clasă

24

Figura II.8: Utilizarea conceptului de Trait

Printre conceptele OOP demonstrate a fi cele mai utile în cadrul acestui proiect se
găsește conceptul de callable . Adăugarea unei funcții callable ca parametru pentru o altă
funcție, și apelarea ei în corpul funcției, având acces la parametrii locali, se evită nevoia de
repetiție – acest lucru fiind demonstrat în
Figura II.9.

25
Figura II.9: Utilizarea conceptului de Callable
Același concept va fi ilustrat și în Figura II.10, în care vom avea o funcție responsabilă
pentru a afișa în terminal /cons olă rezultatele diferitor operații , pasate către această funcție
tocmai prin intermediul unei funcții anonime prin argumentul de tip callable .

Figura II.10: Utilizarea callable – funcția care afișează rezultatele testelor

Prin metoda magică apelată la conversia variabilei $event la tipul string , se va afișa un
rezultat care va avea structura:
[namespace -ul entității]: [memoria consumată] – [timpul de execuție în milisecunde ]

26

Faker este o bibliotecă PH P care generează date false în funcție de necesitățile aplicației .
Este o librărie puternic inspirată de librăria Data::Faker din Perl, respective de librăria Faker
din Ruby, și își găsește utilitate în următoarele situații: [17]
 Crearea rapidă a unei baze de date folosită pentru dezvoltare sau testare
 Crearea unor documente XML cu un aspect plăcut
 Popularea sistemelor de persistență în vederea efectuării unor teste de stres
asupra lor
 Anonimizarea datelor preluate de la un serviciu aflat în producție

În cazul dat, această bibliotecă a fost folosită pentru următoarele două funcții, fiecare
fiind responsabilă de popularea cu date de test a unei entități folosite de către sistem.

Figura II.11: Faker – popula rea entităților Article

După cum se poate vedea și în Figura II.11, utilizarea Faker este relativ simplă, funcțiile
puse la dispoziție în această bibliotecă fiind foarte intuitive.

27

Figura II.12: Faker – popularea entităților Author

Chiar dacă această implementare folosește acces la proprietate, cum se observă în Figura
II.12, fiecare apel către $faker ->name va da un rezultat diferit (aleatoriu). Acest lucru se
datorează faptului că Faker folosește funcția magică __get() a claselor pentru a transmite apelul
la proprietăți către un Generator.
Pentru apelarea tuturor opera țiilor ar fi putut exista mai multe variante de implementare,
cum ar fi varianta utilizării unor Controllere sa u crearea unor comenzi utilizând componenta
Console. Totuși, am ales să folosesc componenta DoctrineFixturesBundle , care permite
încărcarea unui set de date „false” într -o bază de date, care pot fi mai apoi utilizate pentru testare
[18].
În Symfony, fiși erele de tip Fixture sunt clase PHP în care se creează alte obiecte și se
persistă în baza de date. O funcționalitate utilă a fișierelor Fixture integrată în Symfony este
faptul ca framework -ul permite gruparea acestor fișiere, astfel încât să fie executat e în mod
separat. Acest lucru va fi util pentru schimbarea cu ușurință a contextului testelor, prin folosirea
a două grupuri diferite – unul pentru fișierul Fixture pentru entitățile Author, respectiv unul
pentru fișierul Fixture pentru entitățile Article – și executarea lor separată.

28
Capitolul III. Analiza de performan ță

Pentru a analiza performanța fiecărui tip de baze de date, vom rula o serie de teste,
după cum urmează :
 Câte 100.000 operații de INSERT, SELECT și DELETE pentru cazul entității simple
 Cate 30.000 o perații de INSERT, SELECT și DELETE pentru cazul entităților în
relație One -To-Many. Pentru fiecare entitate părinte, vor exista câte 3 entități referite
(fiecare Autor va avea exact 3 volume publicate).

Toate aceste teste vor fi repetate de 5 ori, înreg istrându -se timpul de execuție pe
fiecare iterație, în scopul calculării unui timp mediu de execuție. Pentru relevanța testelor, se
va folosi un număr de operații identic pentru fiecare test. Totuși, pentru a simula cât mai
veridic un context aplicabil în realitate în care aceste baze de date lucrează pe seturi mari de
date, se vor include anumite variabile care vor diferi de la test la test :
 Lungimea datelor inserate (datorita libr ăriei Faker)
 Numărul de articole care vor fi publicate (vor avea se tată o va loare pentru câmpul
published_at , de tip DateTime)

Pentru rularea testelor, se va apela funcția doctr ine:fixtures :load, inclusă în Symfony
prin instalarea pachetului Doctrine, cu urm ătorii parametrii :
 –em – managerul de entități folosit (și implicit baza de date folosită ). Valorile posibile,
după cum au fost definite în configurația Doctrine sunt mysql, postgresql , sqlite
 –group – grupul de Fixtures folosit. În cazul acestei lucrări s -au definit 2 grupuri,
Simple și Join, câte unul pentru fiecare context de folosit pentru testare. Grupul Simple
va executa doar clasa Article Fixture s, prin care se vor popula doar enti tăți de tipul
Article , pe când grupul Join va executa clasa Author Fixtures , prin care se vor insera
entitățile Author , fiecare având relații cu 3 entități Article

29

Figura III.1: Testarea cazului simplu, pe baza de date MySQL (MariaDB)

După cum se poate observa în Figura III.1, serverul Maria DB necesită cel mai mult timp
de execuție pentru operațiile INSERT și DELETE, timpul necesar pentru a efectua SELECT pe
întreg setul de date fiind extrem de mic în comparație cu ceilalți doi timpi.

Figura III.2: Testarea cazului simplu, pe baza de date Postgre SQL

30
Cazul Postgresql, exemplificat în Figura III.2 va avea rezultate similare cu MariaDB,
însă remarcăm un timp necesar pentru DELETE mult mai mic în prima iterație a testă rii.

Figura III.3: Testarea cazului simplu, pe baza de date Sqlite

SQLite, după cum se vede în figura Figura III.3, va oferi timpi de execuție
considerabil mai buni – aproximativ 50% din valoarea timpilor celorlalte baze de date pentru
INSERT, timpuri comparabile pentru SELECT, respectiv o îmbunătățire drastică pentru
timpul de DELETE.

Figura III.4: Testarea cazului One-To-Many, pe baza de date MySQL(MariaDB)

31
În cazul în care vom avea o relație de tip One -To-Many, am ales ca numărul total de
entități asupra cărora se vor efectua operații să fie similar (30.000 Autori * 3 articole per autor
= 90.000 entități), pentru a obține timpi de execuție similari.
În prima iterație a testelor, putem trage următoarele concluzii în cazul bazei de date
MySQL, a cărui rezultat se observă în Figura III.4:
 Timpul de execuție pentru INSERT crește considerabil, cu aproximativ 30 de secunde,
chiar dacă numărul total de entități este cu 10.000 mai mic decât în contextul cu o
singură entitate persistată
 Timpul de SELECT este mult mai rapid, acest lucru datorându -se probabil faptului că
sistemul are o viteză foarte bună de obținer e a datelor dintr -o entitate referite printr -o
relație
 Timpul de DELETE este aproape identic

Figura III.5:Testarea cazului One -To-Many , pe baza de date PostgreSQL

Rezultatele vor fi similare și în cazul P ostgreSQL, care își va menține avantajul în ceea
ce privește timpul de execuție față de MySQL și in acest caz, după cum se poate observa în
Figura III.5

32

Figura III.6:Testarea cazul ui One -To-Many , pe baza de date SQLite

SQLite, după cum se poate observa în Figura III.6, iși va menține performanța deosebită
și în acest context. Ba mai mult, timpul de INSERT ajunge la aproape o treime din timpu l
necesar pentru celelalte tipuri de baze de date.
În ceea ce urmează, se va realiza o sinteză a rezultatelor pe fiecare iterație a testelor,
respectiv pe fiecare tip de bază de date și fiecare context luat în considerare. De asemenea, se
va nota memoria necesară pentru fiecare tip de operație, care va fi identică pentru fiecare iterație
a testelor.

33
III.1 Configurația sistemului
Toate aceste teste vor fi ru late pe un sistem având configurația din Tabelul III.1.

OS Name Microsof t Windows 10 Pro
Version 10.0.19041 Build 19041
System Type x64-based PC
Processor Intel(R) Core(TM) i3 -6100 CPU @ 3.70GHz, 3700 Mhz, 2
Core(s), 4 Logical Processor(s)
BIOS Version/Date American Megatrends Inc. 0216, 9/9/2015
BaseBoard
Manufacturer ASUSTeK COMPUTER INC.
BaseBoard Product H110M2 D3
Installed Physical
Memory (RAM) 8.00 GB
Total Physical Memory 7.94 GB
Available Physical
Memory 3.18 GB
Total Virtual Memory 23.9 GB
Available Virtual
Memory 15.3 GB
Page File Space 16.0 GB
Tabelul III.1: Configurația Sistemului

34
III.2 Testarea MySQL (MariaDB Server)

Time (miliseconds) t1 t2 t3 t4 t5 Avg. Time
Simple entity Insert 71,533 63,545 66,213 68,220 61,982 66,299
Select 1,516 1,188 1,432 1,723 1,654 1,503
Delete 44,977 44,155 43,915 45,211 44,803 44,612
OneToMany Insert 85,715 66,505 76,286 80,214 69,012 75,546
Select 220 239 209 212 257 227
Delete 46,658 47,207 36,827 39,420 51,024 44,227
Tabelul III.2: Rezultatele testelor pentru baza de date MySQL(MariaDB)

Tabelul III.2 va prezenta rezultatele afișate în milisecunde pentru fiecare dintre cele 5
iterații ale testelor. După cum se poate observa, timpul mediu va fi :
 66.2, 1.5, 44.6 secunde pentru operațiile INSERT, SELECT, respectiv DELETE pentru
cazul cu o singură entitate
 75.5, 0.2, 44.2 secund e în cazul relației One -To-Many pentru aceleași operații

De menționat este memoria folosită de către acest tip de bază de d ate la rularea
operațiilor date pe setul de date populate de către Faker , și anume :
 596, 710, 722 MB pentru operațiile INSERT, SELECT, respectiv DELETE pentru cazul
cu o singură entitate
 698, 710, 724 MB în cazul relației One -To-Many pentru aceleași operaț ii

III.3 Testarea PostgreSQL
Time (miliseconds) t1 t2 t3 t4 t5 Avg. Time
Simple entity Insert 62,563 65,257 66,213 63,124 67,233 64,878
Select 1,122 1,211 1,312 1,156 1,249 1,210
Delete 15,597 17,513 16,241 14,980 19,232 16,713
OneToMany Insert 78,330 73,792 75,211 77,934 76,142 76,282
Select 192 217 199 205 220 207
Delete 23,109 23,127 24,215 22,814 22,357 23,124
Tabelul III.3: Rezultatele testelor pe ntru baza de date PostgreSQL

35
După cum indi că Tabelul III.3, rezultatele medii în cu privire la timpii de execuție,
pentru fiecare caz testat pe baza de date PostgreSQL , sunt :
 64.8, 1.2, 16.7 secunde pentru operațiile INSERT, SELECT, respectiv DELETE pentru
cazul cu o singu ră entitate
 76.2, 0.2, 23.1 secunde în cazul relației One -To-Many pentru aceleași operații

Rezultatele referitoare la memoria consumată pentru execuție sunt :
 644, 644, 672 MB pentru operațiile INSERT, SELECT, respectiv DELETE pentru cazul
cu o singură e ntitate
 754, 754, 782 MB în cazul relației One -To-Many pentru aceleași operații

III.4 Testarea SQLite
Time (miliseconds) t1 t2 t3 t4 t5 Avg. Time
Simple entity Insert 27,787 29,788 30,420 28,902 25,683 28,516
Select 1,316 1,355 1,438 1,421 1,293 1,365
Delete 4,475 5,203 4,123 4,426 3,940 4,433
OneToMany Insert 38,262 32,561 75,211 77,934 76,142 60,022
Select 259 252 254 248 560 315
Delete 6,026 5,613 5,842 4,923 5,124 5,506
Tabelul III.4: Rezulta tele testelo r pentru baza de date SQLite

Din nou, drept concluzie rezultatelor medii din Tabelul III.4, SQLite are un avantaj
masiv în ceea ce privește performanța, după cum urmează :
 28.5, 1.3, 4.4 secunde pentru operațiile INSE RT, SELECT, respectiv DELETE pentru
cazul cu o singură entitate
 60, 0.3, 5.5 secunde în cazul relației One -To-Many pentru aceleași operații
Memoria consumată de scripturile rulate în cazul bazei de date SQLite va fi:
 596, 596, 622 MB pentru operațiile INS ERT, SELECT, respectiv DELETE pentru cazul
cu o singură entitate
 698, 698, 720 MB în cazul relației One -To-Many pentru aceleași operații

36
III.5 Sinteza rezultatelor
Pentru a sintetiza rezultatele, vom compara în Figura III.7, Figura III.8, respectiv Figura
III.9 timpul mediu necesar pentru fiecare operație, în ambele cazuri date și pe ntru toate cele trei
tipuri de bază de date.

Figura III.7: Timpul mediu pentru operația INSERT, exprimat în secunde

Figura III.8: Timpul mediu pentru ope rația SELECT , exprimat în milisecunde

Figura III.9: Timpul mediu pentru operația DELETE , exprimat în secunde 0s 10s 20s 30s 40s 50s 60s 70s 80s 90sOne-To-ManySingle EntityTIMPUL MEDIU PENTRU INSERT (secunde)
SQLite PostgreSQL MySQL
0ms 200ms 400ms 600ms 800ms 1,000ms 1,200ms 1,400ms 1,600msOne-To-ManySingle EntityTIMPUL MEDIU PENTRU SELECT (milisecunde)
SQLite PostgreSQL MySQL
0ms 5ms 10ms 15ms 20ms 25ms 30ms 35ms 40ms 45ms 50msOne-To-ManySingle EntityTIMPUL MEDIU PENTRU DELETE (secunde)
SQLite PostgreSQL MySQL

37
În mod similar, Figura III.10, Figura III.11 și Figura III.12 vor prezenta aceeași sinteză,
dar cu privire la memoria consumată la rularea fiecărei operații .

Figura III.10: Memoria necesară pentru operația INSERT

Figura III.11: Memoria necesară pentru operați a SELECT

Figura III.12: Memoria necesară pentru operația DELETE
0MB 100MB 200MB 300MB 400MB 500MB 600MB 700MB 800MBOne-To-ManySingle EntityMEMORIA NECESARĂ PENTRU INSERT ( MB)
SQLite PostgreSQL MySQL
0MB 100MB 200MB 300MB 400MB 500MB 600MB 700MB 800MBOne-To-ManySingle EntityMEMORIA NECESARĂ PENTRU SELECT (MB)
SQLite PostgreSQL MySQL
0MB 100MB 200MB 300MB 400MB 500MB 600MB 700MB 800MB 900MBOne-To-ManySingle EntityMEMORIA NECESARĂ PENTRU DELETE (MB)
SQLite PostgreSQL MySQL

38
CONCLUZII
În concluzie, în această lucrare se propune un studiu de caz asupra posibilită ților de
integrare a trei baze de date diferite, MySQL, SQLite și PostgreSQL – integrate concomitent în
cadrul aceluiași proiect bazat pe framework -ul Symfony și utilizând Doctrine drept strat de
abstractizare al bazelor de date.
S-a urmărit modul în care se poate realiza acest lucru, în ciuda faptului că este un caz
aparte pus în comparație cu majoritatea situațiilor , proiectele utilizând, în mod uzual, un singur
sistem de persistență a datelor. Totuși, întrucât Symfony oferă această posibilititate de a i ntegra
mai multe baze de date simultan, consider util studiul pe această temă pentru îmbunătățirea
cunoștințelor si luarea unor eventuale decizii mai bune pe viitor cu privire la arhitectura
sistemelor implementate.
Tot din motive academice s -au realizat și teste de performanță asupra acestor
implementări, iar concluzia trasă este că există o soluție potrivită pentru fiecare cerință în parte,
fiind sarcina dezvoltatorilor și/sau arhitecților software să cunoască fiecare posibilitate pentru
a putea lua decizii asumate și potrivite.
Bazele de date alese pentru acest proiect sunt MySQL cu MariaDB Server , PostgreSQL
și SQLite. Este contraproductiv să comparăm aceste trei soluții ca răspuns pentru aceeași
problemă. Acest lucru ar duce la o concluzie pripită asu pra aparentei superiorități SQLite
datorită performanței deosebite, mult mai bună decât celelalte două variante.
Deoarece SQLite pune accent pe concepte precum eficiența și economia, este aproape
imposibil să nu aibă rezultate considerabil mai bune la pr oba vitezei de execuție decât MySQL
și PostgreSQL, baze de date care concurează pentru un alt segment al pieței, având ca scop
scalabilitatea, concurența și controlul, atribute mult mai potrivite pentru proiecte de tip
enterprise.
Capitolul I a urmărit p rezentarea tehnologiilor folosite pentru dezvoltarea aplicației,
tehnologii moderne care facilitează implementarea demersurilor de rutină, ceea ce nu numai
crește viteza de dezvoltare, ci și permite concentrarea resurselor dezvoltatorilor către găsirea de
soluții cât mai eficiente la problemele care apar.
În cel de -al doilea capitol se prezintă din punct de vedere tehnic modul de implementare
al arhitecturii propuse , urmărindu -se proiectarea bazei de date, cât și câteva dintre funcțiile de
bază utilizate p entru testare, respectiv câteva componente și concepte Symfony importante

39
pentru cazurile alese , cum ar fi sistemele de Fixtures și Migrations, proiectul de abstractizare al
bazelor de date Doctrine , conceptul OOP de trait și librăria Faker , utilizată pent ru generarea de
date aleat orii, dar similare cu date reale.
În capitolul III s -a analizat performanța celor trei tipuri de bază de date, înregistrându –
se date cu privire la viteza d e execuție și memoria consumată pentru inserarea, selectarea și
ștergerea unui set relativ mare de date în două situații diferite : pentru o singură entitate,
respectiv pentru două entități aflate într -o relație de tip One -To-Many. Fiecare test a fost iterat
de 5 ori, pentru a putea trage concluzii mai asumate cu privire la rezul tate, calculându -se și
comparându -se media tuturor testelor pentru fiecare tip de bază de date.

40
BIBLIOGRAFIE

[1] PHP Manual, http://php.net/manual/en , Consultat la 23.01 .2020
[2] PHP Syntax and Ta gs, https://www.w3resource.com/php/syntax/syntax.php , Consultat
la 26.01.2020
[3] What is Symfony , https://symfony.com/what -is-symfony , Con sultat la 12.02 .2020
[4] Fabien Potencier, Symfony 5: The Fast Track , Sensiolabs, 2019, 2918390372 , Consultat la
17.02.2020
[5] Bruno Paz, An introduction to Symfony | The foundation of modern PHP applications ,
24.12.2018, https://dev.to/brpaz/an -introduction -to-symfony –the-foundation -of-modern -php-
applications -ehj, Consultat la 25.02.2020
[6] François Zaninotto & Fabien Potencier, The Definitive Guide to Symfony, Apress, 2007,
9781590597866, Consultat la 28.02 .2020
[7] Composer Documentation, Introduction , https://getcomposer.org/doc/00 -intro.md ,
Consultat la 3.03.2020
[8] Mike Street, Git f or Beginners: An Overview and Basic Workflow , 2015,
https://www.liquidlight.co.uk/blog/article/git -for-beginners -an-overview -and-basic –
workflow/ , Consultat la 6.03.2020
[9] Database (DB), https://www.techopedia.com/definition/1185/database -db, Consultat la
10.03 .2020
[10] MySQL 8.0 Reference Manual, What is MySql? ,
https://dev.mysql.com/doc/refman/8.0/en/what -is-mysql.html , Consultat la 24.03.2020
[11] About SQLite , https://www.sqlite.org/about.html , Consulta t la 14.04 .2020
[12] Grant Allen, Mike Owens, The Definitive Guide to SQLite,
https://www.apress.com/gp/book/978143023225 4, 2010, Apress, 9781430232254 , Consultat la
16.04.2020
[13] Appropriate us es for SQLite , https://www.sqlite.org/whentouse.html , Consultat la
21.04.2020

41
[14] What is Postgresql? , https://www.postgresql.org/about/ , Consultat la 27.04 .2020
[15] The PostgreSQL Global Development Group , PostgreSQL 13beta1 Documentation ,
https://www.postgresql.org/files/documentation/pdf/13/postgresql -13-A4.pdf , Consultat la
28.04.2020
[16] Richard Stones, Neil Matthew , Beginning Databases with PostgreSQL: From Novice to
Professional , Apress, 2005, 978-1-4302 -0018 -5, Consultat la 3.05.2020
[17] fzaninotto , Faker , https://github.com/fzaninotto/Faker , Consultat la 8.05.2020
[18] Symfony Documentation , DoctrineFixturesBundle ,
https://symfony.com/doc/master/bundles/DoctrineFixt uresBundle/index.html , Consultat la
14.05.2020
[19] PHPStorm Features , https://www.jetbrains.com/phpstorm/features/ , Consultat la
16.05.2020
[20] About MariaDB Server, https://mariadb.org/about , Consultat la 21.0 5.2020
[21] Hossain M, Mahmud S, Santa TD. Oracle, MySQL, PostgreSQL, SQLite, SQL Server:
Performance based, http://dspace.daffodilvarsity.edu.bd:8080/handle/123456789/3363 ,
Consultat la 23.05.2020