Puntatori di una tabella in un DB

[xxxfiles]

Supponiamo di avere una tabella di 100 elementi in un Data Base.
Effettuo una query e supponiamo che il risultato della query e' l'elemento 50. Se ora inserisco un nuovo record esso mi viene inserito tra l'elemento 50 e il 51 ovviamente schiftando tutti gli altri.

Io credevo (sbagliando quindi) che l'inserimento veniva comunque fatto in coda. Mi confermate?

Ora, esiste una funzione per far posizionare il puntatore di questa tabella alla fine in modo che se inserisco l'elemento 101 esso e' inserito in coda senza chiudere e riaprire la connessione al DB?

[xxxfiles]

Nessuno puo' aiutarmi?

[piero.mac]

Da dove hai dedotto tutto cio'?

Non esiste in mezzo o in coda. Esiste un indice e un campo identificativo del record ("deve" esserci sempre).

Se intendi dire invece una lista non ordinata.... beh! per definizione non ordinata ... non e' ne in mezzo ne al fondo.

[xxxfiles]

Forse sono stato poco chiaro ma io ho una tabella fatta da vari campi tra cui un campo id auto_increment che e' una chiave primaria.

Quindi per ogni record inserito, la tabella che ottengo e' naturalmente ordinata per "id" giusto?

Es.

id=1
id=3
id=55
id=66
id=81

Ora se faccio un INSERT il nuovo record avra' id=82 e verra' posto in coda cioe' se visualizzo la tabella con phpmyadmin

visualizzaro' i record in ordine di id

id=1
id=3
id=55
id=66
id=81
id=82


Pero' poi faccio un SELECT ed in base alla query supponiamo che l'elemento selezionato e' quello con id=66.
Se subito dopo faccio un insert la situazione che ho e' questa :

id=1
id=3
id=55
id=83
id=66
id=81
id=82

Ora vorrei sapere se e' normale che sia cosi' ed in tal caso se esiste un modo tale che ,dopo avere fatto un SELECT, se dopo faccessi un INSERT l'elemento venga posto realmente in coda cioe'

id=1
id=3
id=55
id=66
id=81
id=82
id=83

[piero.mac]

E corretto che sia cosi'. quei buchi nella numerazione dell'id sono il risultato di record cancellati. Ora un record cancellato non fa compattare automaticamente la tabella.

La tabella non variera' la sua occupazione di spazio per record cancellati ed al caso (puntatore, spazio sufficiente) andra' ad occupare man mano gli spazi "intermedi" della visualizzazione non ordinata.

Se invece esegui la query: OPTIMIZE TABLE nome_tabella questi spazi "vuoti" verranno compattati migliorando anche le prestazioni generali di operazioni sulla tabella stessa.

Se utilizzi phpMyAdmin nella tabellina "spazio utilizzato dovresti vedere la riga "spazio in eccesso" dopo l'optimize questo verra' eliminato.

Non esiste un "ordine" di storage nel file, ma solo un ordine di visualizzazione indicato da un indice o da una specifica richiesta ORDER BY.

[pinopisc]

a proposito di optimize,

mi chiedo da tempo se sia un' operazione affidabile, esistono rischi documentati che ne sappiate?

[piero.mac]

Originariamente inviato da pinopisc
a proposito di optimize,

mi chiedo da tempo se sia un' operazione affidabile, esistono rischi documentati che ne sappiate?

Tanto quanto aprire e riscrivere un file. Non e' da fare sempre, ma sicuramente dopo grossi cambiamenti e dopo un bel backup della tabella.

[xxxfiles]

Ok piero.mac, grazie per le tue spiegazioni, in effetti ho fatto un po' di prove e le cose sembrano andare proprio come hai descritto.

X pinpisc, beh se non ci sono bug dal punto di vista dell'algoritmo che ottimizza il tutto, credo che la affidabilita' sia la stessa di quella di una operazione di scrittuta o un update di alcuni record.

Ad esempio se c'e' uno sbalzo di tensione o un errore di trasmissione l'operazione non e' affidabile sia se stai facendo un optimize e sia se stai facendo un insert.

Resta il fatto che in caso di errore in un insert potrebbero essere compromessi solo i dati che stai per inserire, mentre in una operazione di ottimizzazione, un errore potrebbe causare la perdita della struttura della tabella e quindi di molti piu' dati.

Cmq un regola d'oro e' che prima di queste operazioni di "massa" e' sempre meglio prima fare una copia.