Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > it.comp.www.php > #22750 > unrolled thread

[OT] Info su BIGINT, INT, etc.

Started by^Bart <gabriele1NOSPAM@hotmail.com>
First post2019-10-26 14:28 +0200
Last post2019-11-08 15:56 +0100
Articles 15 — 4 participants

Back to article view | Back to it.comp.www.php


Contents

  [OT] Info su BIGINT, INT, etc. ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-10-26 14:28 +0200
    Re: [OT] Info su BIGINT, INT, etc. bramante <bramante@yopmail.com> - 2019-10-26 22:19 +0200
      Re: [OT] Info su BIGINT, INT, etc. ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-01 14:33 +0100
        Re: [OT] Info su BIGINT, INT, etc. ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-01 14:47 +0100
          Re: [OT] Info su BIGINT, INT, etc. bramante <bramante@yopmail.com> - 2019-11-01 17:18 +0100
            Re: [OT] Info su BIGINT, INT, etc. ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-02 13:29 +0100
              Re: [OT] Info su BIGINT, INT, etc. Alessandro Pellizzari <shuriken@amiran.it> - 2019-11-04 16:43 +0000
                Re: [OT] Info su BIGINT, INT, etc. ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-06 19:52 +0100
                  Re: [OT] Info su BIGINT, INT, etc. Alessandro Pellizzari <shuriken@amiran.it> - 2019-11-09 10:38 +0000
    Re: [OT] Info su BIGINT, INT, etc. Leonardo Serni <lserni@gmail.com> - 2019-10-27 11:10 +0100
      Re: [OT] Info su BIGINT, INT, etc. ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-01 14:22 +0100
        Re: [OT] Info su BIGINT, INT, etc. ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-01 14:50 +0100
          Re: [OT] Info su BIGINT, INT, etc. Leonardo Serni <lserni@gmail.com> - 2019-11-04 00:02 +0100
            Re: [OT] Info su BIGINT, INT, etc. ^Bart <gabriele1NOSPAM@hotmail.com> - 2019-11-06 20:00 +0100
              Re: [OT] Info su BIGINT, INT, etc. Leonardo Serni <lserni@gmail.com> - 2019-11-08 15:56 +0100

#22750 — [OT] Info su BIGINT, INT, etc.

From^Bart <gabriele1NOSPAM@hotmail.com>
Date2019-10-26 14:28 +0200
Subject[OT] Info su BIGINT, INT, etc.
Message-ID<qp1e4n$7sa$1@gioia.aioe.org>
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

[toc] | [next] | [standalone]


#22751

Frombramante <bramante@yopmail.com>
Date2019-10-26 22:19 +0200
Message-ID<qp29o1$7qg$1@gioia.aioe.org>
In reply to#22750
Il 26/10/19 14:28, ^Bart ha scritto:
> 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

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

[toc] | [prev] | [next] | [standalone]


#22754

From^Bart <gabriele1NOSPAM@hotmail.com>
Date2019-11-01 14:33 +0100
Message-ID<qphc6i$i2l$1@gioia.aioe.org>
In reply to#22751
> 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

[toc] | [prev] | [next] | [standalone]


#22755

From^Bart <gabriele1NOSPAM@hotmail.com>
Date2019-11-01 14:47 +0100
Message-ID<qphd11$lt5$1@gioia.aioe.org>
In reply to#22754
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: 
https://stackoverflow.com/questions/5634104/what-is-the-size-of-column-of-int11-in-mysql-in-bytes

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

[toc] | [prev] | [next] | [standalone]


#22759

Frombramante <bramante@yopmail.com>
Date2019-11-01 17:18 +0100
Message-ID<qphls1$1ub4$1@gioia.aioe.org>
In reply to#22755
Il 01/11/19 14:47, ^Bart ha scritto:
> 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: 
> https://stackoverflow.com/questions/5634104/what-is-the-size-of-column-of-int11-in-mysql-in-bytes 
> 
> 
> 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.
> 

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



> Saluti!
> ^Bart

[toc] | [prev] | [next] | [standalone]


#22761

From^Bart <gabriele1NOSPAM@hotmail.com>
Date2019-11-02 13:29 +0100
Message-ID<qpjsqh$1mge$1@gioia.aioe.org>
In reply to#22759
> 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

[toc] | [prev] | [next] | [standalone]


#22766

FromAlessandro Pellizzari <shuriken@amiran.it>
Date2019-11-04 16:43 +0000
Message-ID<h2b2q0Ffv79U1@mid.individual.net>
In reply to#22761
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:

https://dev.mysql.com/doc/refman/8.0/en/integer-types.html

Tutto il resto è fuffa. :)

Bye.

[toc] | [prev] | [next] | [standalone]


#22767

From^Bart <gabriele1NOSPAM@hotmail.com>
Date2019-11-06 19:52 +0100
Message-ID<qpv4pf$hg8$1@gioia.aioe.org>
In reply to#22766
> 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:
> 
> https://dev.mysql.com/doc/refman/8.0/en/integer-types.html

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

[toc] | [prev] | [next] | [standalone]


#22770

FromAlessandro Pellizzari <shuriken@amiran.it>
Date2019-11-09 10:38 +0000
Message-ID<h2nj95F4c7oU1@mid.individual.net>
In reply to#22767
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:
>>
>> https://dev.mysql.com/doc/refman/8.0/en/integer-types.html
> 
> 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.

[toc] | [prev] | [next] | [standalone]


#22752

FromLeonardo Serni <lserni@gmail.com>
Date2019-10-27 11:10 +0100
Message-ID<u3rarepcqmnaplmpf3o02hhnv5k8cggilr@L.Serni>
In reply to#22750
On Sat, 26 Oct 2019 14:28:07 +0200, ^Bart <gabriele1NOSPAM@hotmail.com> 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
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]


#22753

From^Bart <gabriele1NOSPAM@hotmail.com>
Date2019-11-01 14:22 +0100
Message-ID<qphbji$fae$1@gioia.aioe.org>
In reply to#22752
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

[toc] | [prev] | [next] | [standalone]


#22756

From^Bart <gabriele1NOSPAM@hotmail.com>
Date2019-11-01 14:50 +0100
Message-ID<qphd6e$lt5$2@gioia.aioe.org>
In reply to#22753
> 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

[toc] | [prev] | [next] | [standalone]


#22765

FromLeonardo Serni <lserni@gmail.com>
Date2019-11-04 00:02 +0100
Message-ID<0tmure99ha9fturp80vdk0cj2k6rpkurou@L.Serni>
In reply to#22756
On Fri, 1 Nov 2019 14:50:07 +0100, ^Bart <gabriele1NOSPAM@hotmail.com> 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
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]


#22768

From^Bart <gabriele1NOSPAM@hotmail.com>
Date2019-11-06 20:00 +0100
Message-ID<qpv584$jo8$1@gioia.aioe.org>
In reply to#22765
> 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

[toc] | [prev] | [next] | [standalone]


#22769

FromLeonardo Serni <lserni@gmail.com>
Date2019-11-08 15:56 +0100
Message-ID<k20bsel9lrp41n0c4uinubpbfkot91ar85@L.Serni>
In reply to#22768
On Wed, 6 Nov 2019 20:00:22 +0100, ^Bart <gabriele1NOSPAM@hotmail.com> 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
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [standalone]


Back to top | Article view | it.comp.www.php


csiph-web