Premetto che sono un fan sfegatato degli id interi autoincrementali delle tabelle SQL usati come chiave primaria. Prima o poi tornano utili e fanno comunque comodo.
Un collega qualche giorno fa mi ha detto di essere un po’ perplesso degli id autoincrementali per via del rischio di overflow.
MySQL, infatti, in caso di raggiungimento del limite del contatore autoincrementale non permette di aggiungere ulteriori record. Non è una bella situazione. Mi sono deciso, quindi, a fare un paio di conti.
Ipotizziamo un id autoincrementale di tipo UNSIGNED INT: abbiamo 4 byte di dati, pari a 32 bit pari a 4.294.967.295 in base decimale. Ipotizzando l’inserimento in una tabella di un milione di record al giorno (11 record al secondo) avremmo 4.295 giorni (poco meno di 12 anni) di vita della nostra tabella. Decisamente inaccettabile.
Meglio utilizzare un id autoincrementale di tipo UNSIGNED BIGINT: 8 byte, 64 bit e 18.446.744.073.709.551.615 possibili valori. Se ipotizziamo un miliardo di record al giorno (11.500 al secondo) potremmo avere spazio di crescita per circa 25 milioni di anni. Potrebbe essere sufficiente.
5 risposte a “Id autoincrementale delle tabelle MySQL”
Quando lavoravo negli USA, visto che dovevamo essere compatibili con diversi db (usando Java è di default) il problema non era nel numero, ma nella gestione degli autoincrement field era piuttosto pesante visto che MySQL e MS(6.5, 7.0, 2000) ce lo avevano, ma Oracle ce lo aveva “diverso”…
🙂
Quando Oracle fara’ una cosa standard o uguale agli altri sara’ sempre troppo tardi! 🙂
A dire il vero il concetto di “sequence” non è per nulla stupido o brutto, anzi. In alcuni caso l’ho trovato anche più efficace dell’autoincrement.
Certo è che puoi probabilmente chiedere tutto a Larry Ellison, tranne di seguire gli standard… ma è una malattia comune a quella gente… Gates e Jobs non sono da meno, anzi 🙂
ROTFL! 😀