Mysql e fine degli id

[the darkness]

oppure come ha fatto google che si è personalizzato mysql...

[optime]

ti chiedi perché non riempiono i buchi?

1. che 'incrementale' sarebbe?
2. pensa al tempo che si perderebbe a cercarli 'sti buchi...

[the darkness]

si lo so che a cercarli sarebbe una perdita di tempo....ma ci sono degli espedienti che fanno fare questa cosa in tempo costante.
Per esempio tenere traccia in una fifo di questi buchi sarebbe con costo pari a 0 praticamente.
Basta fare un pop nella pila quando si elimina un buco, e un push se la pila non è vuota quando si inserisce...magari si evitano tanti sprechi.
Ovviamente ci sono anche tante altre strutture se si vogliono implementare features particolari...tipo avl ecc

[comas17]

Originariamente inviato da the darkness
si ho visto...è vero...è tanto...però calcola che per siti belli grossi con tanti recod che vengono eliminati e inseriti, non è un numero invalicabile... non credi?

NO

Con numeri così grandi (e quasi illeggibili) è difficile avere le dimensioni...

Proviamo a fare un esempio:

Immaginiamo una tabella,con campo auto-incrementante di tipo bigint senza segno (da 0 a circa 2 seguito da 20 zeri...)

Immaginiamo di inserire un miliardo di record al secondo (ripeto UN MILIARDO DI RECORD AL SECONDO), tralasciando per un attimo l'aspetto "tecnico" di un database che gestisca un inserimento ogni nanosecondo...

Ecco, (se i miei conti non mi ingannano ) ci vorranno poco meno di 10.000 anni (ripeto DIECI MILA ANNI) per arrivare al limite del bigint...

Continuiamo a preoccuparci ?

[the darkness]

allora proverò a creare uno script che ti stupisca...si ovviamente ci sono persone che ci avranno pensato sicuramente prima di me, però sai...meglio sentire anche da amici colleghi

[daniele_dll]

bisogna essere realisti e pragmatici nelle cose ... quando si mette una chiave primaria numerica auto incrementante si mette INT(10) per il semplice motivo che una tabella con 4 miliardi di record è una tabella che contiene una cifra STRATOSFERICA di record

Facciamo due semplici conti: per finire i record inseribili (ovvero 4294967295) in 100 anni si dovrebbero effettuare 117670 e qualcosa inserimenti al giorno.

Ora, se si deve "giocare", "scherzare" o parlare di "fantasie" personali va bene ... possiamo teorizzare quando vogliamo, ma generalmente tendo ad essere pragmatico: un sito "grosso" generalmente non vive 100 anni, e comunque non fa quella cifra di inserimenti nella stessa tabella al giorno, già che arriva a 10/15 senza subire alcun tipo di ristrutturazione con conseguenziale ristrutturazione e conversione del database (e quindi con un consequenziale tappamento dei buchi) è moltooooooooooooo surreale.

Poi, in realtà, se si fanno previsioni del genere vuol dire che è SBAGLIATO usare una chiave primaria di questo tipo e il problema va analizzato meglio: ad esempio, per una tabella che gestisce le sessioni mettere come chiave primaria un id numerico non ha senso si va a mettere l'id di sessione ^^

[the darkness]

perfetto condivido esattamente quello che dici te.
Pero il problema in realtà è che supponiamo che un sito gestisca 100.000 affiliati (e un sito grosso in genere li gestisce) e supponiamo che ciascuno di questi affiliati magari aggiunge 100 record al giorno (cosa molto comune)
succede che il sito ha 10.000.000 record al giorno nuovi (che se poi vengono cancellati sono comunque id bruciati).
10.000.000 record al giorno, per arrivare a 4294967295 sono 429 giorni....
un anno e due mesi...
E le cifre che ho detto non sono cosi stratosferiche.
Certo, gestire 100000 affiliati avrai i soldi con la pala e magari puoi permetterti di comprare infrastrutture ad hoc...però comunque la cosa poteva essere attutita riempiendo i buchi.
Ora, ovviamente si può passare a bigint tutto quello che vogliamo dire...pero effettivamente questa discussione era anche un mezzo per far conoscere a tutti di fare attenzione quando si progetta la base di dati e soprattutto di fare attenzione con la gestione degli inserimenti e delle cancellazioni.
Magari potrebbe essere spunto per qualcuno, per rivedere un pochetto i lavori come sono stati fatti e rifletterci un po su, anche se sono pienamente consapevole che nella maggiorparte dei casi un sito gestisce talmente tanti pochi inserimenti da non far esistere questo problema.

[optime]

ottimi ragionamenti teorici per un problema che non esiste se c'è la possibilità di usare un bigint (con conseguente elevamento dei limiti superiori a livelli stratosferici) di che ti preoccupi?

[the darkness]

già, si è vero...però in genere cerco sempre di andare oltre e vedere se quello che ci viene servito nel piatto sazia tutta la nostra fame
non fa mai male credo

[daniele_dll]

c'è un errore di fondo ^^

anche fossero 10 milioni di record al giorno, ti faccio notare che per arrivare a 4 miliardi e rotti ci vogliono 400 giorni errotti

ed in ogni caso si usano altri tipi di indici, ad esempio composto dall'anno o dall'anno e dal mese e da un numero sequenziale ... e hai appena risolto il problema

possiamo teorizzare quanto si vuole, ma i problemi si possono risolvere sempre con una buona progettazione

ovviamente quello esposto è una situazione surreale perché per un sistema del genere non usi mysql vai ad usare oracle, db2 o mssql