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

[Radical]

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 disponibila si in stanga lui 0 cu - si in drepata lui zero.

Cod: 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...
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...

In functie de dimensiunea aleasa spatiul pe disk folosit de o inregistrare variaza... dupa corespondenta de mai sus... astfel 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.

Cod: DATE      - 1000-01-01          pana la 9999-12-31            - 3 bytes
DATETIME  - 1000-01-01 00:00:00 pana la 9999-12-31 23:59:59   - 8 bytes
TIMESTAMP - 1970-01-01 00:00:00 pana la 2037... nu este exact - 4 bytes
TIME      - -838:59:59          pana la 838:59:59             - 3 bytes
YEAR      - 1901                pana la 2155                  - 1 bytes

Aici diferenta intre DATETIME si DATE este mult mai evidenta... aici se economiseste 5 bytes la fiecare inregistrare... deci daca nu aveti nevoie de timp folositi cu incredere DATE... sau TIMESTAMP... (unde nu inteleg de ce in manual scrie la maxiumum "undeva in 2037"...)

Cod: CHAR    (X) - de la 0 la 255 caractere
VARCHAR (X) - de la 0 la 255 caractere
Diferenta intre cele 2 tipuri o stie toata lumea, nevoile de stocare sunt si ele diferite... CHAR are nevoie de X bytes... pe cand VARCHAR are nevoie de X+1 bytes... (logic byte-ul in plus este folosit pentru a semnala terminarea valorii...)

Cod: TINYTEXT    - pana la        255 caractere                    -  1 byte peste lungimea string-ului introdus
TEXT        - pana la     65.535 caractere       = aprox 64Kb - 2 bytes peste lungimea string-ului introdus
MEDIUMTEXT  - pana la 16.777.215 caractere       = aprox 16Mb - 3 bytes peste lungimea  string-ului introdus
LONGTEXT    - pana la 184.467.440.73.709.551.615 = aprox. 4Gb - 4 bytes peste lungimea  string-ului introdus

Aceleasi considerente ca si la intregi... in plus dau 2 beri celui care are nevoia de a stoca peste 16Mb de text intr-o celula a unei coloane MySQL... si vreau sa mai vad si timpii de reactie a bazei de date... mai ales ca in general in PHP "memory_limit = 16M"... deci cu siguranta scriptul MOARE... (daca nu se modifica in php.ini)

Cod: ENUM - max. 65.535 valori - 1 byte daca sunt pana in 255 valori, 2 bytes altfel
SET  - max. 64 valori     - (numarul de valori + 7)/8 rotunjit in sus la 1, 2, 3, 4, sau 8 bytes

Multa grija la alegearea coloanelor...
Si TABELE cat mai rapide...

[smallAdmin]

Radical a scris: Aceleasi considerente ca si la intregi... in plus dau 2 beri celui care are nevoia de a stoca peste 16Mb de text intr-o celula a unei coloane MySQL...

si dupa ce ii dai tu 2 beri, ii dau eu 2 suturi in c*r. asta ca sa se invete minte sa puna romane de sandra brown in celula de tabela. :D

[arond]

Radical a scris: ... mai ales ca in general in PHP "memory_limit = 16M"... deci cu siguranta scriptul MOARE... (daca nu se modifica in php.ini)...


SELECT SUBSTRING(sandra_brown_novel FROM 0 FOR 10) AS first_10 FROM...

si script-ul nu moare niciodata :). Point-ul e ca n-au legatura una cu alta, cum gresit s-ar putea intelege.

In rest, perfect de acord.

Numa' bune.

[PHPRomania Bot]