Newsgroup: it.comp.software.database
Titolo: Chiave primaria: meglio unica o multipla

All'università mi hanno sempre insegnato a trasformare un modello
entity-relationship in una serie di tabelle con relative chiavi,
seguendo opportune regole, generando indifferentemente chiavi multiple
se necessario.
Da discussioni recenti con altre persone, mi viene consigliato di
utilizzare sempre e comunque, per tutte le tabelle, una chiave
costituita da un ID di tipo contatore.
Volevo un parere esperto (se qualcuno ha dei link a pagine
sull'argomento va altrettanto bene):
E' vero? E quali sono i pro e i contro delle due soluzioni?
Grazie.

 E' vero? E quali sono i pro e i contro delle due soluzioni?
se hai una chiave unica su ogni tabella le query che farai saranno più 
semplici e di facile interpretazione. con due o più chiavi ti incasini 
più facilmente. e se hai dei valori che devono essere univoci nelle 
tabelle, usa gli indici. mi è capitato un progetto con chiavi priarie 
multiple, e non le ho mai piu usate da allora.

 costituita da un ID di tipo contatore.
[CUT]
Ti porto un esempio,
semplificando al max, devi catalogare un libro, 
avrai una tabella titolo, una tabella autore e una tabella
di relazione tra le due (trTitAut) dato che è una relazione
molti a molti (un libro può essere scritto da più persone, e
una stessa persona può aver scritto più libri)
In questo caso avrai una chiave primaria PKTit sulla tabella Titolo
Una chiave primaria, PKAut, sulla tabella Autore e una chiave 
primaria PKTitAut sulla tabella ponte che è composta dalla chiave 
esterna FKTit, FKAut.
Questo è un esempio tipico di chiave multipla, come risolveresti
 questo utilizzando una sola chiave primaria per ciascuna
delle tre tabelle (sopratutto per la tabella di relazione)? 
Personalmente non mi sono mai piaciute le chiavi contatore (se 
per contatore intendi un id autoincrementante) perchè non ne hai 
il pieno controllo e quando, ad. es., devi fare delle operazioni di
import/ export dei dati la trovo più seccante da trattare (ma questo
è un gusto personale).
ciao
Stefano
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 delle tre tabelle (sopratutto per la tabella di relazione)? 
TabellaPonte
+------+--------+---------+
|  ID  |  PKAut |  PKTit  |
+------+--------+---------+
|  1   |   1    |    1    |
|  2   |   4    |    1    |
|  3   |   5    |    8    |
+------+--------+---------+

 E' vero? E quali sono i pro e i contro delle due soluzioni?
...hmmm... dipende da cosa ti serve nell'implementazione fisica
della base dati. Mi spiego meglio... a basso livello...:)
Ho una tavola T1 con c1, c2, c3 chiave primaria composta.
Se quella tavola T1 la devo metter spesso in join con altre tavole
con la sua chiave primaria, è di gran lunga meglio utilizzare
una chiave primaria fisica (il classico ID) e effettuare join
con quest'ultima, (c1,c2,c3) saranno l'identità della tabella
ovvero chiave logica ovvero chiave alternativa, che ti servirà
principalmente a prenderti l'ID associato ed andarci a spasso
nel dibbì..
Se invece la stessa tabella non la devo mettere in join e
meglio eseguo spesso ricerche sulla sua chiave primaria,
conviene mantenere la chiave composta come fisica e non introdurre
una ulteriore chiave ridondante e inutile...
/G

 +------+--------+---------+
ciao,
così può andare bene se non hai bisogno che il db rispetti ne
l'integrità referenziale ne la relazionalità tra gli elementi, 
in questo caso se non setti la 
FKAut+FKTit come chiave primaria potresti avere lo stesso titolo
con due (o meglio n) autori uguali (incongruenza).
Puoi di certo controllare via codice ma mi sembra un po' scomodo
e "logicamente" scorretto (IMHO).


 Stefano

 
Naturalmente, ma ... fino ad un certo punto. ;-)
ciao


 l'aggiunta di una ulteriore chiave.
si. per comodità. se voglio referenziare autore+titolo lo posso fare con 
un solo id, invece di usarne due.