<div dir="ltr">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). <div>Ci lavoro sopra e vi tengo informato di eventuali sviluppi problematici. </div><div><br><div>Grazie ancora, mi avete dato un bel po' su cui meditare :-)</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 25 settembre 2014 20:34, Samuele <span dir="ltr"><<a href="mailto:samuele.zanin@tiscali.it" target="_blank">samuele.zanin@tiscali.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 25/09/2014 17:18, Davide Posillipo wrote:<br>
> Ciao Marco,<br>
><br>
> grazie mille, sinceramente, della tua fantastica risposta; mi hai<br>
> chiarito diversi punti importanti.<br>
> Nel mio caso i valori dovrebbero essere in teoria praticamente "eterni"<br>
<br>
</span>Appunto, hai scritto "dovrebbero" ed "in teoria".<br>
<br>
Condivido tutto quanto detto da De Paoli.<br>
<span class=""><br>
> Il punto è che sto scrivendo anche il programma e almeno così su due<br>
> piedi mi sembra più facile definire una chiave primaria formata da campi<br>
> già esistenti che crearne una di tipo integer che poi il programma deve<br>
> aggiornare e verificare in automatico (non sono espertissimo di Java).<br>
<br>
</span>Il bello degli id autoincrementanti è che tu definisci il campo e poi si<br>
arrangia il motore sql ad assegnarlo.<br>
Nei casi un cui ti serva sapere l'id del record appena inserito, il<br>
motore sql ti fornisce una funzione da chiamare per ottenerlo<br>
(tipicamente se fai inserimenti su tabelle master/detail).<br>
<br>
Usando chiavi di tipo integer hai il vantaggio che quando fai i join, ti<br>
limiti a mettere un'uguaglianza tra due campi e non devi portarti dietro<br>
3-4 o più campi, semplificando le query.<br>
<br>
So che questo è un argomento caldo, capace di infiammare gli animi tra i<br>
progettisti di database, quindi se volete fare a botte, io sono presente<br>
(e se il presidente si azzarda a calmare le acque meno anche lui).<br>
<span class=""><br>
> Però l'idea mi sembra eccellente e ne farò sicuramente uso in futuro,<br>
> anche perché al momento tratto con db che non superano i dieci milioni<br>
> di record.<br>
<br>
</span>Non sono i pochi byte richiesti dal campo autoincrementante e del suo<br>
indice a fare la differenza in termini di spazio.<br>
Tien conto che i db organizzano i record all'interno di pagine di dati,<br>
quindi di spazio "sprecato" all'interno di queste pagine normalmente ce<br>
ne è, quindi a meno che tu non abbia una lunghezza del record che<br>
rasenta il sottomultiplo della dimensione della pagina, non ti accorgi<br>
dello spazio utilizzato.<br>
E poi alla fine, costa meno lo spazio su disco che il tempo impiegato a<br>
programmare.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
montellug mailing list<br>
<a href="mailto:montellug@montellug.it">montellug@montellug.it</a><br>
<a href="http://mail.montellug.it/mailman/listinfo/montellug" target="_blank">http://mail.montellug.it/mailman/listinfo/montellug</a><br>
</div></div></blockquote></div><br></div>