|
||||||
[OT] Info su BIGINT, INT, etc.
|
||||||
|
|
|
Salve,
<NEWBIE> volevo una delucidazione sul concetto dei RDBMS tipo MySQL/MariaDB di seguito un esempio: CREATE TABLE users ( id_user BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(25), surname VARCHAR(25), FK_id_city INT(10) UNSIGNED NOT NULL, INDEX (FK_id_city), FOREIGN KEY (FK_id_city) REFERENCES cities (id_city) ) ENGINE=INNODB; Io mi immagino visivamente un database come un foglio di excel/calc con tante colonne quante sono i campi quindi la colonna id_user che è un BIGINT può avere molti più valori di quanti ne possa avere la colonna FK_id_city! Ipotizzando di avere come valore massimo di BIGINT 100 e di INT 60 al sessantunesimo inserimento avrei un errore o sbaglio? </NEWBIE> Saluti! ^Bart |
|
|
|
|
|
Il 26/10/19 14:28, ^Bart ha scritto:
[..] > </NEWBIE> > Saluti! > ^Bart no una tabella di tipo innodb (engine) può contenere miliardi di record. id_user definito bigint unsigned vuol dire che può assumere come valore massimo 18446744073709551615 fk_id_city definito int può assumere -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647) Saluti |
|
|
|
On Sat, 26 Oct 2019 14:28:07 +0200, ^Bart <gabriele1NOSPAM> wrote:
>tante colonne quante sono i campi quindi la colonna id_user che è un >BIGINT può avere molti più valori di quanti ne possa avere la colonna >FK_id_city! >Ipotizzando di avere come valore massimo di BIGINT 100 e di INT 60 al >sessantunesimo inserimento avrei un errore o sbaglio? Non sbagli. Ma id_user è un contatore utenti, id_city è un contatore città; se prevedi di poter avere più di 60 città, sbagli ad usare il tipo INT. Nel caso reale, BIGINT arriva a uno stonfo di numeri e INT fino a oltre due miliardi, sicché il problema non si pone. Con BIGINT puoi dare svariati ID a ogni singolo essere umano mai esistito. Leonardo |
|
|
|
Grazie intanto per la risposta! :)
> Non sbagli. Ma id_user è un contatore utenti, id_city è un contatore città; > se prevedi di poter avere più di 60 città, sbagli ad usare il tipo INT. Quindi se volessi sfruttare appieno le caratteristiche di INT UNSIGNED dovrei dargli invece di 60 il valore di 4294967295 giusto? Però se uso un VARCHAR 10 su ogni record mi vengono tagliati i nomi con più di 10 caratteri e se uso INT 10 in teoria mi dovrebbero venire tagliati i numeri che superano le dieci cifre quindi potrei memorizzare il numero 4294967295 perché formato da dieci cifre... > Nel caso reale, BIGINT arriva a uno stonfo di numeri e INT fino a oltre due > miliardi, sicché il problema non si pone. > Con BIGINT puoi dare svariati ID a ogni singolo essere umano mai esistito. Di sicuro ho capito che non mi serve usare BIGINT perché tutti quei valori non mi interessano e la loro memorizzazione (8 byte) avrebbe troppo peso. > Leonardo Saluti! ^Bart |
|
|
|
> no
Ti ringrazio per la risposta e chiedo venia per le mie domande da newbie ma alle volte anche leggendo libri, manuali etc. qualche dubbio magari banale viene! :) > una tabella di tipo innodb (engine) può contenere miliardi di record. > id_user definito bigint unsigned vuol dire che può assumere come valore > massimo 18446744073709551615 > fk_id_city definito int può assumere -2^31 (-2,147,483,648) to 2^31-1 > (2,147,483,647) Quindi il valore massimo che può avere un tipo INT UNSIGNED è 10 perché posso memorizzare al massimo un valore di dieci cifre ovvero 4294967295 anche perché se uso VARCHAR 10 posso memorizzare delle parole fino a dieci caratteri e l'undicesimo mi verrebbe tagliato... > Saluti Saluti e... grazie ancora per la pazienza! :D ^Bart |
|
|
|
Il 01/11/19 14:33, ^Bart ha scritto:
>> no > Ti ringrazio per la risposta e chiedo venia per le mie domande da newbie > ma alle volte anche leggendo libri, manuali etc. qualche dubbio magari > banale viene! :) Ho trovato la suluzione qui: Morale della favola in un campo INT(10) UNSIGNED potrei scrivere un numero fino a dieci cifre quindi 9999999999 per un totale di inserimenti pari a 4294967295 valori! Quindi facendo questa ipotesi di tabella: users ------------------------------- id_user name personal_number 1 Peter 9991234569 2 John 2345435439 Nel caso volessi memorizzare personal_number come numero sarei costretto ad usare lo stesso valore di id_user quindi per entrambi INT o per entrambi BIGINT ed in generale sarebbe meglio usare l'opzione ZEROFILL in modo che 1 diventi 0000000001 e che si possa quindi mettere in ordine crescente/decrescente senza problemi. Saluti! ^Bart |
|
|
|
> Quindi se volessi sfruttare appieno le caratteristiche di INT UNSIGNED
> dovrei dargli invece di 60 il valore di 4294967295 giusto? > Però se uso un VARCHAR 10 su ogni record mi vengono tagliati i nomi con > più di 10 caratteri e se uso INT 10 in teoria mi dovrebbero venire > tagliati i numeri che superano le dieci cifre quindi potrei memorizzare > il numero 4294967295 perché formato da dieci cifre... Credo di aver finalmente trovato la quadra, INT(60) UNSIGNED significa che potrei memorizzare tanti numeri fino ad un massimo di 4294967295 con una lunghezza massima di ognuno di 60 cifre! Saluti! ^Bart |
|
|
|
Il 01/11/19 14:47, ^Bart ha scritto:
[..] > entrambi BIGINT ed in generale sarebbe meglio usare l'opzione ZEROFILL > in modo che 1 diventi 0000000001 e che si possa quindi mettere in ordine > crescente/decrescente senza problemi. dipende... se personal_number è univoco per ogni user allora si, puoi inserire al max il numero di righe dato dal valore massimo di int(10) unsigned e cioè 4294967295 righe, ma se personal_number non è univoco puoi inserire al max il numero di righe dato da id_user bigint(20) unsigned e cioè 18446744073709551615 righe. ma se il tuo caso è il primo, personal_number univoco, il campo user_id diventa inutile. quale è secondo il tuo utilizzo lo scopo di user_id? Saluti |
|
|
|
> ma se il tuo caso è il primo, personal_number univoco, il campo user_id
> diventa inutile. Hai ragione! > quale è secondo il tuo utilizzo lo scopo di user_id? Nel caso specifico, come ti ho già accennato dandoti ragione, non ha alcun senso il campo user_id mentre invece devo capire concettualmente la gestione dei dati numerici! Partiamo dal presupposto che non può esistere un INT(11) perché il valore massimo di cifre memorizzabile con tale tipologia è di 10! Nel caso dovessi memorizzare come numero dei numeri le cui cifre sono maggiori di dieci dovrei usare BIGINT che come valore massimo ha 20. Nel caso dovessi memorizzare un numero con più di venti cifre dovrei memorizzarlo come stringa ovvero VARCHAR. Volendo potrei inserire milioni anzi miliardi di record (ovviamente non univoci!) in un campo INT(10) perché il limite è, detto volgarmente, sulla larghezza della riga e non su quante righe (record) andrò ad inserire! > Saluti Ragionandoci sopra ho capito gli errori concettuali che compivo! Saluti! ^Bart |
|
|
|
On Fri, 1 Nov 2019 14:50:07 +0100, ^Bart <gabriele1NOSPAM> wrote:
>> Quindi se volessi sfruttare appieno le caratteristiche di INT UNSIGNED >> dovrei dargli invece di 60 il valore di 4294967295 giusto? >> Però se uso un VARCHAR 10 su ogni record mi vengono tagliati i nomi con >> più di 10 caratteri e se uso INT 10 in teoria mi dovrebbero venire >> tagliati i numeri che superano le dieci cifre quindi potrei memorizzare >> il numero 4294967295 perché formato da dieci cifre... >Credo di aver finalmente trovato la quadra, INT(60) UNSIGNED significa >che potrei memorizzare tanti numeri fino ad un massimo di 4294967295 >con una lunghezza massima di ognuno di 60 cifre! No: INT(60) significa che puoi memorizzare un massimo di 4294967295 (quindi nove cifre "e mezza"). Il Display Width ha senso solo se è PIU' PICCOLO del massimo numero di cifre rappresentabili. Che so: INT(8) o INT(6). Credo sia compreso il segno, quindi INT(11) ha senso. Ma forse prima è meglio chiarire un altro punto: "cos'è che ti serve"? Leonardo |
|
|
|
On 02/11/2019 12:29, ^Bart wrote:
> Partiamo dal presupposto che non può esistere un INT(11) perché il > valore massimo di cifre memorizzabile con tale tipologia è di 10! Un suggerimento spassionato: ignora quel numero tra parentesi. Guarda qui per sapere il numero massimo per ogni tipo intero: Tutto il resto è fuffa. :) Bye. |
|
|
|
> Un suggerimento spassionato: ignora quel numero tra parentesi.
Ah ok, quindi se si volesse sfruttare il valore massimo si potrebbe omettere tale valore? > Guarda qui per sapere il numero massimo per ogni tipo intero: > Il valore 4294967295 per INT UNSIGNED è il numero massimo di record (volgarmente righe) che posso inserire nella tabella mentre scrivere INT(11) significa che ogni cella potrà ospitare al massimo un numero di undici cifre? > Tutto il resto è fuffa. :) A me interessa capire la logica per poi decidere se usare INT, BIGINT, TINYINT, etc. > Bye. Saluti! ^Bart |
|
|
|
> No: INT(60) significa che puoi memorizzare un massimo di 4294967295 (quindi
> nove cifre "e mezza"). Il Display Width ha senso solo se è PIU' PICCOLO del > massimo numero di cifre rappresentabili. Che so: INT(8) o INT(6). Credo sia > compreso il segno, quindi INT(11) ha senso. Scusa ma faccio fatica a capire la logica di tutto questo, immaginiamoci un database come un foglio di Excel o Calc, ogni cella può essere formattata come testo, numero, etc. Se una cella la imposto come INT(60) vuol dire che in ogni singola cella potrò memorizzare un numero fino a 60 cifre per un totale, avendo impostato quella colonna come INT UNSIGNED, di 4294967295 record/righe? > Ma forse prima è meglio chiarire un altro punto: "cos'è che ti serve"? A me interessa prima di tutto chiarire le idee per poi decidere in autonomia quale possa essere la scelta migliore per memorizzare i dati! :) > Leonardo Saluti! ^Bart |
|
|
|
On Wed, 6 Nov 2019 20:00:22 +0100, ^Bart <gabriele1NOSPAM> wrote:
>Se una cella la imposto come INT(60) vuol dire che in ogni singola cella >potrò memorizzare un numero fino a 60 cifre No, che in quella cella ci puoi mettere un INT. Siccome gli INT sono numeri da -2miliardiespicci a +2miliardiespicci, in quella cella ci potrai mettere tutto quello che vuoi... purché sia un numero intero compreso fra +/- 2mldcirca. Se ci vuoi mettere qualcos'altro, devi cambiare tipo di dato. Specificare INT(60) non ti serve a nulla: fa conto che "INT" sia un boccale da undici litri. Puoi dire al barista di metterci cinque litri - INT(5) - come di mettercene 20 - INT(20). Ma ora indovina cosa succede quando versi 20 litri di birra in un boccale da 11? Leonardo |
|
|
|
On 06/11/2019 18:52, ^Bart wrote:
>> Un suggerimento spassionato: ignora quel numero tra parentesi. > Ah ok, quindi se si volesse sfruttare il valore massimo si potrebbe > omettere tale valore? Non ho idea da dove arrivi quel valore tra parentesi. L'unica cosa che i computer capiscono sono i bit. Un numero a 8 bit contiene 256 valori: da 0 a 255 se unsigned, da -128 a +127 se signed. Tutto il resto è un tentativo di renderli user friendly. Fallito. :) >> Guarda qui per sapere il numero massimo per ogni tipo intero: >> > Il valore 4294967295 per INT UNSIGNED è il numero massimo di record > (volgarmente righe) che posso inserire nella tabella mentre scrivere > INT(11) significa che ogni cella potrà ospitare al massimo un numero di > undici cifre? Ignora il numero di cifre. Quello è per gli umani. Stai parlando a un computer. Il numero di cifre per un INT UNSIGNED è 32 (bit). Non è il numero massimo di record che puoi inserire. È il numero massimo di identificatori univoci che puoi assegnare alle righe se usi INT UNSIGNED per l'identificatore. > A me interessa capire la logica per poi decidere se usare INT, BIGINT, > TINYINT, etc. Devi usarlo come id? Allora fatti questa domanda. Quante righe pensi di metterci (ora e in futuro)? Meno di 4 miliardi? Usa INT UNSIGNED. Più di 4 miliardi? Usa BIGINT UNSIGNED. Non vale la pena usare gli altri tipi per un id (o AUTO INCREMENT, come lo chiama MySQL), sia perché noi umani siamo pessimi a predire il futuro, sia perchè dimensioni inferiori non portano nessun guadagno prestazionale o di occupazione del disco significativi. Bye. |
|
|