mysql campi smallint

[IcedGlow]

buon giorno
ho una domanda in merito i campi di mysql.. ho un campo id smallint auto increment che è anche la chiave primaria.. una volta raggiunti 65535 record cosa succede? dovrei strutturare lo script in modo che una volta raggiunto l'id 65535 esegua automaticamente un alter table per modificare l'ampiezza del campo?

[piero.mac]

Originariamente inviato da IcedGlow
buon giorno
ho una domanda in merito i campi di mysql.. ho un campo id smallint auto increment che è anche la chiave primaria.. una volta raggiunti 65535 record cosa succede? dovrei strutturare lo script in modo che una volta raggiunto l'id 65535 esegua automaticamente un alter table per modificare l'ampiezza del campo?

Modifica il campo in INT(10) e saluti suonatori. Ci penseranno i tuoi figli ad ampliarlo...

[IcedGlow]

Originariamente inviato da piero.mac
Modifica il campo in INT(10) e saluti suonatori. Ci penseranno i tuoi figli ad ampliarlo...

bella risposta

già che mi trovo metto BIGINT

[piero.mac]

Originariamente inviato da IcedGlow
bella risposta

già che mi trovo metto BIGINT

Guarda che non e' uno scherzo. con INT(10) UNSIGNED arrivi ad oltre 4 miliardi di record, con MEDIUMINT 3 BYTE ad oltre 16 milioni (UNSIGNED).

Per rispondere alla domanda che succede quando si riempie? Semplice ricomincia da 0, e poi si blocca al primo doppione che trova perche' un auto increment deve essere univoco. SMALLINT UNSIGNED 2 byte:

vedi in binario 11111111 11111111 se sommi + 1 diventa:

1 00000000 00000000 cioe' zero con 2 byte di valori.

[IcedGlow]

Originariamente inviato da piero.mac
Guarda che non e' uno scherzo. con INT(10) UNSIGNED arrivi ad oltre 4 miliardi di record, con MEDIUMINT 3 BYTE ad oltre 16 milioni (UNSIGNED).

Per rispondere alla domanda che succede quando si riempie? Semplice ricomincia da 0, e poi si blocca al primo doppione che trova perche' un auto increment deve essere univoco. SMALLINT UNSIGNED 2 byte:

vedi in binario 11111111 11111111 se sommi + 1 diventa:

1 00000000 00000000 cioe' zero con 2 byte di valori.

vabbè.. ma a livello di ottimizzazione del database?
memoria e spazio?
io volevo partire con i campi non troppo grandi e ingrandirli solo quando ne ho bisogno?

[piero.mac]

Originariamente inviato da IcedGlow
vabbè.. ma a livello di ottimizzazione del database?
memoria e spazio?
io volevo partire con i campi non troppo grandi e ingrandirli solo quando ne ho bisogno?

Si tratta di un byte. Equivalente di un digit VARCHAR. Il campo INT numerico lo gestisce come bit map.

Un campo INT(10) 4 byte occupa meno spazio di un VARCHAR(4) per scrivere la parola "ciao", perche' VARCHAR(4) + 1 byte delimitatore della lunghezza campo.

[IcedGlow]

Originariamente inviato da piero.mac
Si tratta di un byte. Equivalente di un digit VARCHAR. Il campo INT numerico lo gestisce come bit map.

Un campo INT(10) 4 byte occupa meno spazio di un VARCHAR(4) per scrivere la parola "ciao", perche' VARCHAR(4) + 1 byte delimitatore della lunghezza campo.

non immaginavo proprio

[daniele_dll]

ehm...non mettere bigint...non fare follie...hai idea di quanto sia grande bigint...neanche la microsoft lo usa per segnare il numero di copie pirata

mmm ti riporto quello che dice il manuale di mysql sul bigint

BIGINT[(M)] [UNSIGNED] [ZEROFILL]
A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615. Some things you should be aware of with respect to BIGINT columns:

* All arithmetic is done using signed BIGINT or DOUBLE values, so you shouldn't use unsigned big integers larger than 9223372036854775807 (63 bits) except with bit functions! If you do that, some of the last digits in the result may be wrong because of rounding errors when converting a BIGINT value to a DOUBLE. MySQL 4.0 can handle BIGINT in the following cases:
o When using integers to store big unsigned values in a BIGINT column.
o In MIN(col_name) or MAX(col_name), where col_name refers to a BIGINT column.
o When using operators (+, -, *, and so on) where both operands are integers.
* You can always store an exact integer value in a BIGINT column by storing it using a string. In this case, MySQL performs a string-to-number conversion that involves no intermediate double-precision representation.
* The -, +, and * operators will use BIGINT arithmetic when both operands are integer values! This means that if you multiply two big integers (or results from functions that return integers), you may get unexpected results when the result is larger than 9223372036854775807.

PS:
18.446.744.073.709.551.615

esistono i quatriliardi?
oltre i biliardi non so che viene

[Tymba]

se hai un database che memorizza record per i quali è necessario un bigint forse è il caso che cominci a pensare di prendere un capannone per infilarci tutti i tuoi server

[IcedGlow]

Originariamente inviato da Tymba
se hai un database che memorizza record per i quali è necessario un bigint forse è il caso che cominci a pensare di prendere un capannone per infilarci tutti i tuoi server

dicevo per dire