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

[daniele_dll]

[supersaibal]Originariamente inviato da 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.

[/supersaibal]

si ok ... ma una chiave primaria serve a identificare una riga di un database in maniera univoca, per dirla terra terra ... e se mi devo basare su certi criteri per fare il riconoscimento ... non è che non uso una chiave primaria, ma una unica ... uso lo stesso una chiave primaria ...

io mi sono trovato in situazioni abbastanza particolari dove avevo una tabella che non aveva una chiave primaria e usava 6 valori per indentificare in maniera UNIVOCA una riga ... (la tabella non è mia ) ... non è che ci sono molte altre scelte ... dipende da quello che devi fare usare o meno una chiave primaria e come usarla ... molti neanche gradiscono l'uso perenne delle chiavi primarie ... che deve starci per forza in ogni tabella altrimenti caput ...

dipende dalle situazioni il come scrivere ed il come strutturare la tabella ... e se c'è questo rischio ... siccome una volta fatto il tutto cambiare sarebbe una tragedia ... si fa prima

non so se mi spiego, non è che non è vero quello che hai riportato, ma è tutta teoria astratta, perché poi ci sono situazioni dove quelle diciture non possono per niente andare applicate, e una è questa ad esempio ...

metti che ho una tabella dove tengo dei documenti protocollati quindi DEVO avere una codice di protocollo che mi identifica il documento ... ovvero devo aveer una chiave primaria ... i codici di protocollo variano, ma non mi è mai capitato di vedere un numero che si incrementa e basta ... e quindi hai 2 alternative ... o usi 2 campi o ne usi 1 ... però dipende da quello che devi fare ... xche se usi 1 campi e i 4 valori più significativi li affibbi ad es all'anno ... avrai quindi 6 valori che rimangono ... ovvero 999999 documenti protocollabili ... dipende chi ci lavora e chi fa cosa ... la situazione potrebbe anche non reggere ... oltre al fatto che in ogni cosa il sistema di protocollazione deve seguire quello applicato su carta ... e al comune di licata ad esempio facevano anno, mese, e numero progressivo ... e avevano un ambaradan di roba ...

dipende poi sempre TUTTO dalla situazione nella quale si ci trova ... se si possono rispettare e seguire quelle regole senza dubbio, io in primis, quando faccio le tabelle, la chiave primaria è sempre un ID numerico auto-increment ... ma ci sono situazioni dove questo non va bene e si deve cambiare

[andr3a]

timidamente ...

ti fai uno script che prende tutti i records ...


$queries = Array();
$query = mysql_unbuffered_query( 'SELECT * FROM tabella' );
while( $r = mysql_fetch_row( ) ) {
array_push( $queries, 'INSERT INTO tabella VALUES ( NULL, "'.$r[0].'", "'.$r[1].'" )' );
}

mysql_unbuffered_query( 'TRUNCATE TABLE tabella' );
for( $a = 0, $b = count( $queries ); $a < $b; $a++ ) {
mysql_unbuffered_query( $queries[$a] );
}

insomma il concetto e' questo, cosi' tutte le cancellate non occupano piu' una "posizione id" , riordini il database e lo fai una volta ogni 5 anni

[skidx]

andrea, se quelle chiavi primarie sono foreign key su altre tabelle diventa un po' più complicato, per non dire un casino

[piero.mac]

E bravo andr3a... Si tratta del sesso degli angeli. 4 miliardi di record nel suo db non li vedra' manco il nipote. Anche perche' moooolto prima dovra' cambiare server, database e anche l'applicativo.

@daniele... dici bene quando sostieni che si deve fare secondo il proprio bisogno. Ma non e' detto che il tuo bisogno deve essere uno standard per gli altri. E sopratutto non e' mai vero che il proprio caso sia "un caso speciale".

Lo standard e' quello che ho postato prima. Il resto sara' anche necessario ma in ogni caso peggiorativo, a volte necessita la purga ma non sara' mai la bevanda abituale. Punto e basta.

Il resto e'

[andr3a]

davo per scontato che tutte le dipendenze fossero a loro volta aggiornate ... ma era solo una timida, appunto, soluzione non citata

[skidx]

[supersaibal]Originariamente inviato da piero.mac
Si tratta del sesso degli angeli.[/supersaibal]

ma scusa piero (o devo chiamarti mac? ), che parte di "in linea teorica" non ti è chiara?

Siamo tutti d'accordo, mi sembra, che nelle nostre applicazioni PRATICHE sia sempre preferibile usare una chiave primaria numerica in autoincrement, su questo non ci piove.
E' la cosa più pratica, efficiente, veloce, e una applicazione media non avrà MAI problemi di overflow durante il suo ciclo di vita.

Ora, dato questo per scontato, mi ripeto, io provavo a ragionare in via teorica. "Supponiamo di avere una applicazione che necessiti di X miliardi di inserimenti, nel suo ciclo di vita". E' un problema teorico, adesso, ma non è detto che resti teorico in futuro o in condizioni molto particolari.

[piero.mac]

[supersaibal]Originariamente inviato da andr3a
davo per scontato che tutte le dipendenze fossero a loro volta aggiornate ... ma era solo una timida, appunto, soluzione non citata [/supersaibal]

Andr3a, questa e' una discussione sterile anche dal punto di vista teorico. Mysql non andra' mai a quei livelli. Database a quei livelli sono ben pochi e "NON" usano l'autoincrement ma dei trigger molto piu sofisticati e su server di altra portata.

Come dire che si discute del sesso degli angeli, per poi scoprire quando si definira' il sesso, che non se ne fara' nulla perche' sono troppo piccoli.

Lascio qui.



ps. Skidx casualmente ho risposto anche al tuo ultimo post.

[andr3a]

ok, scusate la timida risposta, volevo solo aggiungere una caxxata non considerata, non lo faccio piu', giuro

[skidx]

[supersaibal]Originariamente inviato da piero.mac
Database a quei livelli sono ben pochi e "NON" usano l'autoincrement ma dei trigger molto piu sofisticati e su server di altra portata.[/supersaibal]

Scusami, se esistono questi dbms, che gestiscono in maniera più sofisticata questo problema, sarà mica perché qualcuno si è posto il problema teorico, esattamente come ho fatto io ora?

Una risposta al mio quesito quindi è "il problema viene risolto con dmbs in grado di gestire questa mole di inserimenti tramite chiavi primarie 'sofisticate', che superano i limiti del normale autoincrement".

Io, conscio della mia ignoranza, prendo atto e ringrazio, ma se uno certe cose non se le chiede, è difficile che le impari per caso.

[daniele_dll]

beh ... mi avete costretto ... ora faccio 4 miliardi di insert e vedo che succede ...


addio mondo

pro provo a fare qualche select .....

PS: gli insert li faccio in C# ...