<div dir="ltr">Ciao Marco, <div><br></div><div>grazie mille, sinceramente, della tua fantastica risposta; mi hai chiarito diversi punti importanti. </div><div>Nel mio caso i valori dovrebbero essere in teoria praticamente "eterni" in quanto non è prevista una successiva interazione da parte di utenti per modificare il db. Accedo direttamente con SQL. </div><div><br></div><div>L'idea di usare un costraint unique mi intriga e ammetto che non ci avevo pensato, però mi porta ad un'altra difficoltà tecnica dovuta al tipo di implementazione della base di dati che sto progettando. </div><div>In pratica verrà popolata tramite un programma Java che con JDBC leggerà un flusso indefinito di file XML dallo schema costante e scriverà sul db i dati estratti. </div><div>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). </div><div><br></div><div>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. </div><div><br></div><div>Grazie ancora di cuore della risposta e degli spunti da esperto :)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 25 settembre 2014 16:57, Marco De Paoli <span dir="ltr"><<a href="mailto:depaolim@gmail.com" target="_blank">depaolim@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ciao Davide,<br>
<br>
Il 25 settembre 2014 16:26, Davide Posillipo <<a href="mailto:dav.posillipo@gmail.com">dav.posillipo@gmail.com</a>><br>
ha scritto:<br>
<div><div class="h5">> Buongiorno a tutti,<br>
><br>
> sto cercando di realizzare una base di dati relazionale a partire da un<br>
> modello ER che ho man mano ridotto eliminando entità e relazioni che mi<br>
> sembravano ridondanti.<br>
><br>
> Ora che sto traducendo il tutto in termini di relazioni (tabelle), mi sono<br>
> accorto che una di queste relazioni ha come chiave primaria una chiave<br>
> composta da quattro attributi.<br>
><br>
> La mia domanda è: avere relazioni con chiavi primarie composte da diversi<br>
> attributi potenzialmente può portare a situazioni problematiche? Qual è, se<br>
> esiste, un compromesso accettabile tra numero di relazioni e non ridondanza<br>
> delle informazioni (senza ricorrere alle forme normali)?<br>
<br>
</div></div>in linea di massima ti direi che dipende da un sacco di cose<br>
il tipo di questi campi? i valori, una volta caricati, sono veramente<br>
scolpiti nella roccia oppure potrebbero cambiare? come accedi alla<br>
base dati? direttamente in SQL oppure usi un ORM? l'ORM ha dei limiti?<br>
(es. vuole solo chiavi singole? ce ne sono ce ne sono...)<br>
<br>
io per esempio tendo a definire una singola chiave primaria id di tipo<br>
integer e ottenere in questo modo criteri di join e foreign key puliti<br>
puliti<br>
<br>
ovvio che poi se voglio un vincolo di unicità su una tupla composta da<br>
più campi mettero un constraint unique sulla combinazione dei campi<br>
<br>
(a quel punto ti creerà anche un indice unique che quindi ti velocizza<br>
le ricerche con quel criterio)<br>
<br>
certo ti ritroverai con due indici (la chiave primaria più lo unique)<br>
quando potresti averne uno solo...<br>
<br>
ok, ma con il costo moderno degli storage non è un grosso problema<br>
<br>
mi potresti obiettare che due indici significa anche doppio<br>
aggiornamento in caso di insert/update. Ok, ma anche le i cicli di<br>
clock delle CPU non costano poi così tanto ;-)<br>
<br>
perchè soprattutto, se effettivamente i valori dei campi in chiave<br>
possono modificarsi nella "storia" del record<br>
tanto più se sono più di uno<br>
<br>
Beh, il fatto di tenere consistenti le foreign key sarà una cosa che<br>
ti devi smazzare tu da logica applicativa, mentre invece se sono<br>
collegati per id sono legati per sempre e non ci pensi più<br>
<br>
insomma torniamo alla mia osservazione iniziale: dipende<br>
certo, se stiamo parlando di centiania di milioni di record magari la<br>
cosa ha il suo impatto... parliamone<br>
<br>
just my 2 c<br>
<br>
><br>
> Grazie per l'attenzione,<br>
<br>
de nada,<br>
a proposito, non credo di aver ancora mai partecipato attivamente alla lista<br>
per cui ... ciao a tutti!<br>
<br>
Marco<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>
</blockquote></div><br></div>