faretesto > comp.www.* > comp.www.php

^Bart (26.10.2019, 14:28)
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
bramante (26.10.2019, 22:19)
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
Leonardo Serni (27.10.2019, 12:10)
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
^Bart (01.11.2019, 15:22)
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
^Bart (01.11.2019, 15:33)
> 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
^Bart (01.11.2019, 15:47)
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
^Bart (01.11.2019, 15:50)
> 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
bramante (01.11.2019, 18:18)
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
^Bart (02.11.2019, 14:29)
> 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
Leonardo Serni (04.11.2019, 01:02)
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
Alessandro Pellizzari (04.11.2019, 18:43)
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.
^Bart (06.11.2019, 20:52)
> 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
^Bart (06.11.2019, 21:00)
> 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
Leonardo Serni (08.11.2019, 16:56)
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
Alessandro Pellizzari (09.11.2019, 12:38)
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.
Discussioni simili