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

[Davide Posillipo]

Grazie anche a te, Samuele. In effetti portarsi dietro una chiave con
quattro campi (di tipi differenti) non è molto promettente per la
semplicità delle query, e poi per quanto posso blindare il db nulla
impedisce che un giorno ci sarà o sarà necessaria una modifica (anche a
causa della natura non totalmente affidabile degli XML che importo).
Ci lavoro sopra e vi tengo informato di eventuali sviluppi problematici.

Grazie ancora, mi avete dato un bel po' su cui meditare :-)

Il giorno 25 settembre 2014 20:34, Samuele <samuele.zanin a tiscali.it> ha
scritto:

> 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.
>
>
> _______________________________________________
> montellug mailing list
> montellug a montellug.it
> http://mail.montellug.it/mailman/listinfo/montellug
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://mail.montellug.it/pipermail/montellug/attachments/20140925/341aab57/attachment-0001.html>