Lunghezza campo INT

[LucianoS]

nel mio db c'è una tabella con un campo int(2) che ha come tipo di chiave "unica" e "autoincrementante".

Da pagina web php son riuscito ad inserire anche record a 3 cifre (100,101...). Come mai succede ciò se la lunghezza del campo è int(2)? non dovrebbe storare dati fino ad un massimo di due cifre (fino a 99)?

[piero.mac]

Originariamente inviato da LucianoS
nel mio db c'è una tabella con un campo int(2) che ha come tipo di chiave "unica" e "autoincrementante".

Da pagina web php son riuscito ad inserire anche record a 3 cifre (100,101...). Come mai succede ciò se la lunghezza del campo è int(2)? non dovrebbe storare dati fino ad un massimo di due cifre (fino a 99)?

no. Il campo e' di dimensione fissa di 4 byte. quel (2) si riferisce solo alle cifre da evidenziare e non pone un limite alla capacita' nominale del campo.

Usa tinyint che si limita ad occupare un solo byte. (da -128 a +127) oppure 0 - 255 se UNSIGNED

In pratica quel INT(2) serve solo a definire quanti zero devono essere visualizzati di fronte al numero in caso di campo INT zerofill.

[LucianoS]

quindi potrei arrivare ad inserire anche 15200 record?
e dimmi, con tinyint potrei lo stesso inserire migliaia di record?

[piero.mac]

Originariamente inviato da LucianoS
quindi potrei arrivare ad inserire anche 15200 record?
e dimmi, con tinyint potrei lo stesso inserire migliaia di record?

Con INT puoi inserire oltre 4 miliardi di record.

Qui trovi la tabella dimensione/capacita' per i campi numerici.

http://dev.mysql.com/doc/refman/5.0/...ric-types.html

cerca integer types

[LucianoS]

ok, ho visto la tabella.

Premesso che userò solo dati unisgned, cioè senza segno + o - che precede il numero.

Mi serve per i classici id utente, id prodotti ecc. puoi vedere per cortesia come procedo?

1. per gli ID utenti, tinyint1 (al posto di int4) sapendo gà che non ci saranno più di 255 record
2. per gli ID dei prodotti, smallint2 (al posto di int8) che arriva fino a 65mila
3. se so già che un valore avrà sempre 10 cifre fisse (es. unixtime) posso usare int10?
4. da phpmyadmin, scegliendo Tinyint, mi lascia la possibilità di digitare anche la lunghezza: se metto 2 raddoppio gli iniziali 255 e così via?
5. il numero tra le tonde si riferisce al numero delle cifre da visualizzare.. ma visualizzare dove?
6. lo stesso discorso vale anche per char e varchar? nella stessa tabella ho entrambi i campi.

[piero.mac]

Originariamente inviato da LucianoS
ok, ho visto la tabella.

Premesso che userò solo dati unisgned, cioè senza segno + o - che precede il numero.

Mi serve per i classici id utente, id prodotti ecc. puoi vedere per cortesia come procedo?

1. per gli ID utenti, tinyint1 (al posto di int4) sapendo gà che non ci saranno più di 255 record
2. per gli ID dei prodotti, smallint2 (al posto di int8) che arriva fino a 65mila
3. se so già che un valore avrà sempre 10 cifre fisse (es. unixtime) posso usare int10?
4. da phpmyadmin, scegliendo Tinyint, mi lascia la possibilità di digitare anche la lunghezza: se metto 2 raddoppio gli iniziali 255 e così via?
5. il numero tra le tonde si riferisce al numero delle cifre da visualizzare.. ma visualizzare dove?
6. lo stesso discorso vale anche per char e varchar? nella stessa tabella ho entrambi i campi.

1. Ok.
2. Ok.
3. Ok.
4.5. Non raddoppi nulla. Tinyint e' lungo un byte, percio' sono 8 bit. Si tratta solo della visualizzazione delle cifre 0 da anteporre quando si usa zerofill. Stesso discorso di prima con INT. Le cifre sono tagliate solo se eccedono la lunghezza prefissata dal tipo di campo numerico scelto e non dalla lunghezza indicata nella dichiarazione del tipo di campo.

1 -> tinyint(1) unsigned zerofill = 1
1 -> tinyint(2) unsigned zerofill = 01
1 -> tinyint(3) unsigned zerofill = 001

6. char e' un campo di lunghezza prefissata dal valore tra parentesi. E' statico.
varchar e' un campo di lunghezza max prefissata ma dinamico come occupazione.
statico = lunghezza del campo assegnata sempre tutta impegnata.
dinamico = occupa solo lo stretto spazio necessario alla stringa + un indice di lunghezza.

[LucianoS]

ottima spiegazione.
Sulla base dei tuoi suggerimenti, vorrei risistemare il db.

1. ho indicato smallint2 per gli ID dei prodotti. Leggendoti meglio, direi che smallint1 va più che bene, visto che gli ID non avranno degli 0 iniziali.
2. sulla tabella dei prodotti ho una chiave primaria su IDProdotto. Diminuendo la lunghezza ed il tipo di campo, immagino ci saranno di problemi. Dovrei fare qualche operazione prima e/o dopo?

[LucianoS]

aggiungo un'altra cosa che sto verificando:
la tabella prodotti ha ora un campo tinyint(1) che corrisponde al tinyint(1) della tabella utenti, per vedere quali prodotti sono stati inseriti da quali venditori.

Mi capita che inserendo un prodotto, questo venga inserito nel db con utente_id 127; se invece a quel campo specifico l'attributo UNSIGNED ecco che l'utente_id viene inserito correttamente.
é un problema del db o va sempre specificato quell'attributo?