Comments on: Optimizarea bazelor de date: agregarea datelor

By: Mihai Brehar

Mihai Brehar — Tue, 30 Sep 2008 15:43:43 +0000

@Antoniu, mersi pentru un comentariu asa stufos.

Legat de MyISAM vs. InnoDB, când văd o aplicaţie de contabilitate sau una de gestiune de stoc folosind MyISAM, mi se scoala părul de pe mâini. De ce să execuţi o serie de teste, când poţi să foloseşti foreign keys?

Legat de restul comentariului, repet a treia oară, optimizarea cu agregarea datelor trebuie făcută cu cap, atunci când e nevoie.

By: Antoniu-George SAVU

Antoniu-George SAVU — Tue, 30 Sep 2008 15:29:25 +0000

Prima remarca: nu exista o versiune MySQL 5, exista un 5.0.x si o versiune 5.1.x, care va iesi la sfarsitului lui 2008, inceput 2009. Diferentele de la 5.0 la 5.1 sunt majore.

A doua remarca: folosirea MyISAM e inca de actualitate. Alegerea motorului de stocare, InnoDB sau MyISAM, depinde foarte mult de tipul de date care urmeaza sa fie stocate in tabele. Ca exemplu, avind doua tabele pe care vrei sa le ‘legi’ logic, nu trebuie sa folosesti implicit InnoDB ci sa executi o serie de teste pe date relativ reale si sa te asiguri ca InnoDB e mai rapid decit MyISAM cu replicarea actiunilor de DELETE/UPDATE implementate la nivel aplicativ.

A trei remarca: in versiunea actuala, 5.0, triggerele nu garanteaza punerea la zi a unui cimp. Exista inca destul de multe probleme de acces concurent la date care apar in servere MySQL incarcate cum trebuie ( > 2500 qps.). Utilizarea unei tabele adiacente, cu risc de introducere a unei redundante la nivelul datelor stocate, e mai mult decit recomandata.

A patra remarca: un JOIN nu e neaparat costisitor. Daca tabelele (coloanele) care intra in componenta JOIN-ului nu sunt puse la zi foarte des, MySQL va returna ultimul rezultat (query_cache). O baza de date care are tabele indexate cu grija si care are o structura ingrijita fara aberatii de tipul ‘pun tip de cimp la TEXT in loc de VARCHAR(64) doar ca sa stochez numele clientului’ poate sa se dovedeasca extrem de rapida la un JOIN chiar daca seturile de date implicate depasesc citeva milioane de inregistrari.

Ar trebui sa refaci articolul dupa o documentare mai serioasa si eventual sa alegi un exemplu mai percutant.

By: Mihai Brehar

Mihai Brehar — Mon, 29 Sep 2008 05:31:21 +0000

@sirrocco, am specificat în articol că exemplul este simplist, nu am vrut să pun cititorii să citească un query pe 3 rânduri. Bineînteles, nu trebuie să faci agregarea de fiecare dată când ai un join și un sum().

By: sirrocco

sirrocco — Mon, 29 Sep 2008 03:53:51 +0000

Nu stiu daca iti dai seama dar exemplul dat este unul destul de simplist si care nu ajuta foarte mult pentru ca in 90% din cazuri TREBUI sa ai o tabela separata pentru comenzile clientului.

Intr’adevar, denormalizarea este practicata dar de la un anumit nivel in sus . Nu merita incurajata chestia asta pentru ca fiecare gigel cu 3 tabele zice ca il costa mai mult un join decat o normalizare . Ceea ce e destul de stupid.

Iar cand chiar este nevoie, deja e cineva care se pricepe in spatele bazei de date .

altfel, cei care inca sunt la mysql4 … nu cred ca stiu de foreign key & the like.