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

[Capone]

salutare

am si eu o problema vreau sa creez o baza de date in care sa am persoane , echipamente si alte ...... si vreu sa creez si un istoric..

ex. unei persoane x ii atribui un calculator y ; dupa o perioada acel calc y il atribui altei persoane z .

eu m-am gandit sa creez:
o tabela cu persoane si campurile aferente ;
o tabela cu cechipamente si campurile aferente;
o tabele de istoric in care sa inregistrez din tabela persoane id acesteia si din tabela echipamente id acestuia .
De fiecare data cand se face o modificare de atribuire/redistribuire echipament sa va produce o noua inregistrare in tabela istoric.
aceasta va creste o data cu mutarile / casarea echipamentelor deci la infinit ??credeti ca e ok ?

baza de date as vrea sa fie mai complexa dar asta e un inceput si vreu sa o gandesc bine ca sa fie si scalabila pe viitor.

alte pareri cum sa fac mai bine ???
10x

[gabysolomon]

structura pare OK.
si nu cred ca ai motive sa iti faci griji de numarul de inregistrari in tabele de istoric. am citit de site-uri care tin tabele de stat de ordinul 100.000 de inregistrari pe zi in tabele mysql si nu au probleme. Totul tine de indexarea cat mai buna a bazei de date si de numarul de inregistrari returnate in query-urile facute

[ebogdan]

100.000 inregistrari pe zi, dar numai cu InnoDB, in nici un caz cu MyISAM. Am avut o aplicatie care la 500k - 1 milion inregistrari crapa tabela MyISAM.

[gabysolomon]

sunt deacord ca pentru o astfel de tabela este recomandat InnoDB.
Insa limitarea MyISAM nu e chiar asa mica.
Am o tabela de 1.230.000 de inregistrari si la o marime de 185Mb si care merge perfect. Sigur daca dai un SELECT cu multe inregistrari returnate ... o sa dureze un pic .. dar asta tine de volumul de date returnat.

[Capone]

nu se pune problema de 100.000 inregistrari pe zi . Poate in timp o sa ajunga la 100.000 de inregistrari in tabela de istoric. Pb esta ca aceasta nu va putea fi stersa/golita niciodata deoarece ai nevoie de istoric.
Exista alta metoda ? sau se face altcumva chestia asta cu istoricul.?

va multumesc

[mihaitha]

Metoda e buna. Numai trebuie sa ai grija sa inserezi la fiecare operatiune si corespondentul in tabela istoric. O alta varianta ar fi sa lucrezi cu baza de date PostgreSQL si triggere.

[Capone]

10x man

[Capone]

se poate face spre exemplu dupa x timp ca creezi un al doilea tabel istoric si sa fac interogari in ambele tabele "istoric" ex. afiseaza tot ce gaseste in istoric si istoric1 ?
Aceasta interogare duce la marirea timpilor de afisare a rezultatului cautarii??cu mult ??

[dechim]

in optimizarea bazelor de date se specifica compromisul care trebuie facut intre a avea informatie redundanta si o optimizare la maxim - din acest punct de vedere. Resurse sunt si memoria RAM si timpii cat aplicatia tine procesorul ocupat nu numai spatiul pe hard. Eu as pune ceva informatie redundanta si in istoric. Astfel incat la multe interogari sa nu am nevoie de join cu "persoane" si "echipamente".
Si o arhivare (copiere istoric in alta tabela) prin meniu, sa alega operatorul cand vrea sa faca treaba asta si tot in meniu i-as pune "consultare arhiva", nu mi-as pune problema sa interoghez ambele tabele simultan.

[PHPRomania Bot]