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

[Askary]

Am si eu o intrebare .... de ce folositi mai mereu pt. campurile integer bigint ?

[whitewizzard]

eu unu nu am inteles intrebarea :P

[vectorialpx]

Askary, intrebarea ta putea postata intr-un alt thread... deci o sa il pun eu... dar sper sa realizezi ca nu e bine sa postezi intrebari diferite in thread-uri diferite

bigint are o dimensiune mare [suporta 20 de cifre]
E bine sa fie un numar ce suporta o dimensiune mare pentru cheia primara pentru ca nu se poate sti ce scucces va avea aplicatia si cate milioane de vizitatori o sa ai... in alta ordine de idei, daca tu ai 12 vizitatori, aia e... ai la dispozitie 20 de cifre... pentru a utiliza 2 dintre ele :)

[Radical]

Hai sa-ti spun si eu parerea... ma uitam la un fisier scris de mine cu multi ani in urma... uite ce scriam atunci... relativ la intregi...:

Citat: O chestie destul e prost inteleasa sunt tipurile de date in MySQL... "Data Types"...
Si in general sunt folosite dupa ureche... hai sa pun INT ca sa imi ajunga... chiar daca nu o sa atinga 4 miliarde de inregistrari niciodata...

Sa vedem...

Numere intregi... cele mai folosite pentru coloane auto_increment... mai toti programatorii se arunca direct la INT sau la BIGINT... dar cat pot duce...

Voi expune mai jos numai intregii UNSIGNED... deci doar numere pozitive... daca folositi si numere negative... pentru a afla capacitatea maxima impartiti la 2 si (in linii mari) aceeasi cantitate o sa fie disoponibila si in stanga lui 0 cu - si in drepata lui zero.

TINYINT - de la 0 la 255 - 1 byte
SMALLINT - de la 0 la 65.535 - 2 bytes
MEDIUMINT - de la 0 la 16.777.215 - 3 bytes
INT - de la 0 la 4.294.967.295 - 4 bytes (peste 4 miliarde !!!)
BIGINT - de la 0 la 184.467.440.73.709.551.615 - 8 bytes (atentie la cifra... peste 180 de milioane de miliarde)

Se impune o estimare cat mai exacta a nevoilor tabelului... nu are rost sa punem BIGINT cand de fapt SMALLINT ne satisface nevoile...

Exemplu:
- daca se adauga zilnic 2 articole pe zi intr-un tabel... SMALLINT tot ne satisface nevoile pentru ~89 de ani...
- la 10 articole pe zi intr-un tabel... SMALLINT tot ne satisface nevoile pentru ~17 de ani...

Daca totusi intram in impas... putem apela la MEDIUMINT sau in cel mai rau caz la INT...
Dau o bere celui care imi arata un tabel intr-o baza de date, care are nevoie de BIGINT... evident pentru componente cheie-> facturi, utilizatori inregistrati, etc.

In functie de dimensiunea aleasa spatiul pe disk folosit de o inregistrare variaza... dupa corespondenta de mai sus... la un tabel cu 10.000 de inregistrari daca punem SMALLINT in loc de INT economisim 20.000 bytes... dar cel mai important marim viteza de citire din tabel...

Un lucru prost inteles este declaratia "INT(3) UNSIGNED". Aceasta declaratie NU inseamna ca putem stoca in acel camp de la 0 la 999. De fapt in aceasta forma 3 nu are nici o valoare... ca sa aiba valoare corect ar fi fost "INT(3) UNSIGNED ZEROFILL"... ceea ce NU inseamna ca serverul va stoca numere de la 000 la 999... in acel camp vor putea fi puse valori mai mari de 999 dar la acele valori MySQL nu va mai adauga 0 in fata... el va face padding cu 0 numai la intregii pana in 999: pe 1... il va face 001, pe 27 il va face 027... numarul maxim care poate fi stocat ramane 4.294.967.295.

Nu e o crima sa mai dai un ALTER TABLE din cand in cand... eu dau zeci de ALTER TABLE-uri la fiecare release !!! Un INT il poti transforma in BIGINT...

Ei bine dupa atatia ani de zile... textul meu e inca in parte de actualitate... odata cu timpul am mai crescut si eu... si am aflat ca e bine totusi sa pui INT pentru procesoarele pe 32 de biti care ruleaza sisteme de operare pe 32 biti ptr. ca operatiile sunt optimizate... la fel cum e bine sa pui BIGINT pentru procesoarele pe 64 de biti care ruleaza sisteme de operare pe 64 biti... DAR tot nu pun... am o retinere... intretin un site cu zeci de mii de useri... iar tabela "Users" incepe cu SMALLINT... nu cu INT... si in nici un caz cu BINGINT... Nici macar tabela de "UsersLogins" nu incepe cu BIGINT...

Spatiul pe disk nu mai pune probleme... discurile de 1TB pot fi cumparate pentru acasa... sunt in jur de 1.100RON...

ORICUM de abia asa zisele "Data Warehouse"-uri depasesc 4 miliarde de inregistrari per tabel...

Have fun... choose wise...

[PHPRomania Bot]