[mysql] quando l'autoincrement arriva alla fine, che si fa?

[skidx]

Come da titolo.

So bene che usando un campo BIGINT come chiave in autoincrement ce ne vuole tanto prima di arrivare al limite, ma supponiamo per un attimo di avere una applicazione con una quantità impressionante di inserimenti (e cancellazioni, tanto l'autoincrement cresce comunque). Quando si arriva al limite che si fa?

Come si gestisce la cosa?

[piero.mac]

Con un campo INT(10) UNSIGNED ti stanno 4 miliardi e fischia di record. Ammesso che fai 1.100.000 incrementi al giorno ne avresti per oltre 10 anni.

Credo che dovrai cambiare prima il database.

Per inciso quando riempie i 4 byte di uno, il successivo bit non fara' altro che riportare tutti i 4 byte a 0 con un bit di overflow.

[daniele_dll]

beh...in pratica o di da errore o riparte da zero dato che il bit di overflow (e di conseguenza il byte dato che vanno a gruppi di 8) è a sinistra, tra quelli significanti ... quindi teoricamente non doverbbe scriverlo

(per significanti si intendono i bit che hanno un maggior valore, o per meglio dire ... per insignificanti il contrario ovviamente ^^

[skidx]

[supersaibal]Originariamente inviato da daniele_dll
(per significanti si intendono i bit che hanno un maggior valore, o per meglio dire ... per insignificanti il contrario ovviamente ^^ [/supersaibal]

daniè, sono perito informatico e studio ingegneria informatica

Forse ho posto male la domanda, non intendevo sapere come si comporta il dbms in caso di limite raggiunto, intendevo dire come secondo voi bisognerebbe gestire la cosa a livello di applicazione.

[daniele_dll]

pardon

cosa occorrerebbe fare? mmm archiviare il db cosi com'è e metterne su uno nuovo da zero?

le pk autoincrement, in questo genere di situazioni sono sconsigliate ... proprio per questo motivo ... in questi casi si usa una pk su un campo o su più campi

ovvero ti costruisci ad esempio la chiave usando 2 campi ... anno e un valore che autoincrementi nell'insert ... e sempre nella insert usi la funzione year (che se non erro, se non passi parametri, restituisce l'anno corrente) per il campo anno ... e hai appena aggirato il problema, senza perdere più di tanto di performance

la data ti basta metterla come smallint 5 e l'id incrementante annuo lo metti come a int 10 ... fare + di 4 miliardi di insert in un anno ... è praticamente impossibile ... ma se sei preoccupato ci aggiungi pure un campo mese ... di tinyint 2 (o 3 che tanto è la stessa cosa) e sei al sicuro al 100%

l'unica seccatura e che ti tocca farti una select max(campo) from tabella where anno=YEAR() AND mese=MONTH() (se usi il mese)

xo ... alla fin fine il db, praticamente, neanche se ne accorgi, dato che stai estraendo per una chiave e cercando usando i primi 2 campi della chiave primaria (se ad esempio usavi anno e id non usava la chiave primaria per cercare)

[skidx]

uhm, questa di usare un campo data come parte della chiave mi sembra un'ottima idea, anche perché quello resterà a 4 cifre ancora per un po'

Comunque non mi hanno assunto per ristrutturare il database di Google, era solo una curiosità "didattica"

[piero.mac]

[supersaibal]Originariamente inviato da skidx
uhm, questa di usare un campo data come parte della chiave mi sembra un'ottima idea, anche perché quello resterà a 4 cifre ancora per un po'

Comunque non mi hanno assunto per ristrutturare il database di Google, era solo una curiosità "didattica" [/supersaibal]

il numero intero e' sempre la miglior soluzione. Rapida ed infinita checche' se ne dica. Una data se inserita con insert multipla assegna a tutti i record lo stesso datetime. Se devi unire piu' campi vai contro la semplicita' che deve avere una chiave primaria.

Il resto e' solo cercare di far nutella con la mortadella. Magari ci riesci, ma sapra' di mortadella.

[skidx]

[supersaibal]Originariamente inviato da piero.mac
Rapida ed infinita checche' se ne dica.[/supersaibal]

In un computer non c'è nulla di infinito. Se parliamo di ragionevoli approssimazioni, d'accordo, è una comodissima soluzione, io la uso sempre, ma non sarà mai infinito. Siccome io in questo momento volevo vedere il problema dal punto di vista teorico, non mi accontento del "ragionevolmente grande" di un campo int.

[supersaibal]
Una data se inserita con insert multipla assegna a tutti i record lo stesso datetime. Se devi unire piu' campi vai contro la semplicita' che deve avere una chiave primaria.[/supersaibal]

Le chiavi primarie multiple esistono, anche nei database normalizzati. Che sia scomoda non ci piove, ma appunto mi focalizzavo sull'aspetto teorico, non sulla praticità.

[daniele_dll]

[supersaibal]Originariamente inviato da piero.mac
il numero intero e' sempre la miglior soluzione. Rapida ed infinita checche' se ne dica. Una data se inserita con insert multipla assegna a tutti i record lo stesso datetime. Se devi unire piu' campi vai contro la semplicita' che deve avere una chiave primaria.

Il resto e' solo cercare di far nutella con la mortadella. Magari ci riesci, ma sapra' di mortadella.


[/supersaibal]

ma tu hai una chiave primaria ... fatta con 2 campi ... ed il tempo di esecuzione è esattamente lo stesso di quello di una chiave singola ... xche del resto lui estrai i dati dall'accoppiata campi<->riga e tira fuori le righe ... di conseguenza c'è un campo ... c'è ne sono 10 ... non fa tantissima differenza

[piero.mac]

Tutte storielle... i presupposti per una chiave primaria sono i seguenti... e non me la sono inventata io. La miglior chiave primaria "deve" rispondere di NO ai seguenti quesiti

Condition: Best Answer is NO.

Not Null: Will the candidate value ever be null? no
 
Brevity: Is the candidate value more than a single column? no
 
Simplicity: Does the candidate value contain embedded spaces,
            special characters, or differential capitalization? no 

Data Type: Is the candidate value something other than a number
           or fixed-length character data type? no
 
Nonidentifying Value: Does the candidate value contain any 
                      intelligence or have any meaning? no
 
Never Change: Is the candidate value likely to change? no

Solo un campo numerico risponde NO a tutti i quesiti. Qualunque altra cosa e' fattibile. Ma non sara' mai il meglio.

Poi ognuno attacca il carro dove gli pare. Purche' sia felice e giocondo.