[MontelLUG] A proposito di SQL e database - domanda inerente al corso di SQLite

Samuele samuele.zanin a tiscali.it
Gio 25 Set 2014 20:34:06 CEST


On 25/09/2014 17:18, Davide Posillipo wrote:
> Ciao Marco, 
> 
> grazie mille, sinceramente, della tua fantastica risposta; mi hai
> chiarito diversi punti importanti. 
> Nel mio caso i valori dovrebbero essere in teoria praticamente "eterni"

Appunto, hai scritto "dovrebbero" ed "in teoria".

Condivido tutto quanto detto da De Paoli.

> Il punto è che sto scrivendo anche il programma e almeno così su due
> piedi mi sembra più facile definire una chiave primaria formata da campi
> già esistenti che crearne una di tipo integer che poi il programma deve
> aggiornare e verificare in automatico (non sono espertissimo di Java). 

Il bello degli id autoincrementanti è che tu definisci il campo e poi si
arrangia il motore sql ad assegnarlo.
Nei casi un cui ti serva sapere l'id del record appena inserito, il
motore sql ti fornisce una funzione da chiamare per ottenerlo
(tipicamente se fai inserimenti su tabelle master/detail).

Usando chiavi di tipo integer hai il vantaggio che quando fai i join, ti
limiti a mettere un'uguaglianza tra due campi e non devi portarti dietro
3-4 o più campi, semplificando le query.

So che questo è un argomento caldo, capace di infiammare gli animi tra i
progettisti di database, quindi se volete fare a botte, io sono presente
(e se il presidente si azzarda a calmare le acque meno anche lui).

> Però l'idea mi sembra eccellente e ne farò sicuramente uso in futuro,
> anche perché al momento tratto con db che non superano i dieci milioni
> di record. 

Non sono i pochi byte richiesti dal campo autoincrementante e del suo
indice a fare la differenza in termini di spazio.
Tien conto che i db organizzano i record all'interno di pagine di dati,
quindi di spazio "sprecato" all'interno di queste pagine normalmente ce
ne è, quindi a meno che tu non abbia una lunghezza del record che
rasenta il sottomultiplo della dimensione della pagina, non ti accorgi
dello spazio utilizzato.
E poi alla fine, costa meno lo spazio su disco che il tempo impiegato a
programmare.




More information about the montellug mailing list