Forum PHP Romania - Discutii despre PHP, MySQL, Javascript, AJAX, etc

[Amazing Science]

Vreau sa fac o interfata web (cu php si apache) ce are in spate o baza de date cu multe informatii.

Toti jucatorii de fotbal, de la toate cluburile, din toate diviziile, din toate campionatele, din toate tarile europei.

In mare, informatiile de identificare, foarte pe scurt sa zicem, vor fi:
- tara
- campionat
- divizie
- club
- jucator

Pe aceasta baza de date vreau sa pot face cautare din interfata web. Intrebarea mea e cum sa implementez baza de date - toate inregistrarile intr-o tabela sau in mai multe tabele, pe tari? In care din cele 2 cazuri utilizatorul interfetei va primi mai repede raspuns la o cautare de genul "toti jucatorii de la clubul A din divizia B din campionatul C din tara D" ?

Multumesc.

[mihaitha]

Ideea e sa ai cat mai putine informatii redundante. De exemplu nu are rost sa tii dubletul tara-divizie in aceeasi tabela intrucat nu toate tarile au aceleasi divizii, deci ajunge sa stii divizia ca sa stii si tara.
Eu as tabelele cam asa:
jucatori - id_jucator, id_club, alte informatii (nume, varsta etc.)
cluburi - id_club, id_tara, alte informatii
divizii - id_divizie, id_tara, nume
campionate - id_campionat, nume
legaturi_divizi - id_divizie, id_club
legaturi_campionate - id_campoinat, id_club
tari - id_tara, nume

(am lasat id_tara si in cluburi si in divizii pentru ca un club poate fi si intr-o divizie, si intr-un campionat - care nu e necesar sa fie ceva national).

[Amazing Science]

ok, deci raspunsul ar fi ca merge mai repde daca fac 5-6 select-uri in 5-6 tabele mai mici decat un singur select intr-un tabel mare?

[Birkoff]

Amazing Science a scris: ok, deci raspunsul ar fi ca merge mai repde daca fac 5-6 select-uri in 5-6 tabele mai mici decat un singur select intr-un tabel mare?

dimpotriva, faci 1 singur select folosind joinuri si tinand partile de tabel mai des folosite in cache :D

[Amazing Science]

ok, select cu join-uri

dar... cum tin in cache partile folosite mai des?

[Amenthes]

S-ar putea sa nu ai nevoie de cache. Implementeaza baza de date, pune indecsii de rigoare, realizeaza query-ul care iti trebuie si daca merge bine e ok. Daca merge greu mai optimizeaza putin, cu EXPLAIN query si cautari pe Google si daca nici dupa asta nu merge bine de abia atunci poti sa te gandesti la un cache. Eu personal folosesc Zend_Cache din Zend Framework cand e vorba sa cache-uiesc rezultate.

[Amazing Science]

ok, multumesc tuturor pentru sfaturi. daca voi mai avea nevoie de ajutor voi reveni.

[Amazing Science]

inca o intrebare: folosesc mysql pentru baza de date - ce credeti ca ar fi mai indicat sa folosesc? MyISAM sau InnoDB ?

[Amenthes]

http://rackerhacker.com/2007/11/06/when-to-use-myisam-or-innodb/

[Amazing Science]

ok, am citit.

dar, avand in vedere ca v-am spus pe scurt ce vreau sa fac, voi ce-ati folosi daca ati fi in locul meu? MyIsam sau InnoDb?

momentan parca m-as duce pe MYIsam. Daca peste 3 ani sa zicem ajung la limita de 4,284,867,296 rows, pot trece pe InnoDB sau e mai greu?

mersi.

[Amenthes]

Eu unul as merge pe MyISAM. Acolo unde stiu ca or sa fie multe SELECT-uri aleg MyISAM. Unde sunt multe inserturi si eventual am nevoie de tranzactii folosesc InnoDB.

[Amazing Science]

bun, asa ma gandesc si eu, sa ma duc pe myisam. dar daca la un moment dat ajung la limita si trebuie sa trec pe innodb se poate? ce implicatii ar avea aceasta trecere?

[ebogdan]

Mi se par foarte ciudate întrebările astea despre InnoDB vs. MyISAM. InnoDB are securitate și fiabilitate mult mai mare decât MyISAM, este mai rapid în aproape orice privință (și la INSERT, și la SELECT), are optimizări mult mai bune etc. Iar MyISAM e totalmente varză, nu suportă nici măcar chei străine sau tranzacții, deci nu ar trebui să mai fie considerat bază de date în ziua de azi decât la categoria „glume proaste”.

Deci orice ai face, tot InnoDB e mai bun.

Oricum, momentan MyISAM este menținut doar ca să aibă și cei care habar n-au de baze de date ceva cu care să se joace și să zică că se pricep și ei la ceva. Căci la modul cel mai serios, de altceva nu e bun.

Și despre cache: vezi că MySQL suportă query cache și key cache. Google it!

[Amenthes]

@ebogdan, ai uitat de faptul ca MyISAM suporta indexare FULLTEXT.

E unul dintre motivele pentru care Flickr nu a putut renunta complet la MyISAM. Ma rog, nu stiu ce au ei in prezent, dar acum vreun an asa spuneau intr-o prezentare.

[ebogdan]

Nu am uitat de FULLTEXT. L-am omis pentru că nu mi se pare importantă această facilitate. De ce zic asta: e mai ușor să emulezi un FULLTEXT decât chei străine și tranzacții. Pur și simplu faci un modul cu o tabelă de cuvinte, tabelă cu articolele unde apar, de câte ori, scorul, etc etc etc și mai pui și un filtru să omiți cuvintele uzuale. Evident, index pe cuvânt.

Rezultă o căutare FULLTEXT emulată, universală pentru toată aplicația, care va funcționa comparabil de bine cu cea din MyISAM.

Pe de altă parte, cheile străine sunt greu de emulat. La fiecare ștergere, actualizare sau inserare în tabelă (și chiar și la selectări) trebuie să faci o grămadă de verificări. Sau, mai rău, trebuie să le facă cine scrie helperele de DB, și nu poți fi mereu sigur că nu uită ceva.

Iar tranzacțiile nu le poți emula programatic. Numai motorul de DB în sine poate face totul corect, la nivel de fișier și loguri.

[PHPRomania Bot]