Newsgroup: it.comp.software.database
Titolo: chiavi esterne

Fino a qualche giorno fa ho sempre utilizzato il campo ID (contatore)
per creare relazioni tra le tabelle ma ora mi sorge un dubbio.
Ammettiamo di avere due tabelle: ARTICOLI e CATEGORIE e un SITOWEB che
utilizza queste due tabelle.
ARTICOLI
---------
Id
FkIdCategoria
Nome
---------
CATEGORIE
---------
Id
Nome
---------
I record in queste tabelle vengono inseriti dall'amministratore del sito
e in ognuno è previsto un campo NOME anch'esso univco.
In certe pagine del sito devo mostrare gli articoli di una categoria
es:"GIOCATTOLI".
Per farlo ho due modi: 
1) faccio una query su CATEGORIE, estraggo l'id della categoria
GIOCATTOLI e poi filtro i record degli ARTICOLI
2) faccio un unica query con un join tra le due tabelle
DOMANDA :
In casi come questo non sarebbe meglio utilizzare il nome della
categoria (che è univoco) come chiave esterna piuttosto che un campo
contatore?
Che problemi posso incontrare utilizzando questa soluzione?
grazie
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

grazie
A mio avviso in sostanza fai quello che ti č piů comodo. 
L'uso di un campo auto_increment non č obbligatorio.
In quasi tutti i casi esistono molte chiavi candidate, cioč campi o
insiemi di campi che potrebbero fungere da chiave primaria. Ad esempio
in una tabella "persone" il codice fiscale č certamente una potenziale
chiave primaria perfetta. Anche l'insieme dei campi
Nome+cognome+datanascita+luogonascita potrebbe essere una chiave
candidata (abbastanza improbabile anche se non impossibile che lo
stesso giorno nello stesso posto nascano due persone con lo stesso
nome).
Cosě in una tabella Libri l'ISBN o nella tabella prodotti il Barcode .
Il fatto č che spesso queste chiavi sono scomode (troppo lunghe,
difficilmente individuabili ad occhio, facilmente soggette ad errori)
quindi uno ne crea una piů semplice ad esempio con il contatore.
Invece nel tuo caso, se sai che la categoria č univoca, puoi benissimo
usarla come chiave primaria. Ricorda solo che una chiave primaria: 1.
non puň assumere valore NULL 2. non puň contenere valori duplicati.
Ciao
Matteo

L'uso di un campo auto_increment non è obbligatorio.
Aggiungo. Nella tua decisione devi mettere sulla bilancia il fatto che
un bel dì potresti dover cambiare i campo "categoria" di uno o più
record (anche ad esempio, a causa di un banale errore di battitura).
Se categoria è la PK, questo ti comporta che devi aggiornare a cascata
tutti i record che fanno riferimento a quella chiave nelle tabelle
correlate.
Ora, primo, con MySQL ad esempio, che non gestisce l'integrità
referenziale, questo non avviene automaticamente ma va fatto a mano; 
secondo, anche nei DBMS che gestiscono l'integrità referenziale, su
grandi numeri di record questo potrebbe comportare parecchio lavoro al
dbms.
Usando campi contatore, questa esigenza non ti si proporrà mai perché
il suo valore non ha alcun riferimento con gli attributi reali
dell'entità che identifica, quindi in teoria non avrai mai l'esigenza
di modificare il valore del campo contatore. In teoria, perché non è
detto che questo dato sia del tutto insignificante: a qualcuno
disturba ad es. il fatto che in molti dbms, un campo contatore, una
volta cancellato un record, salta quel numero, e quindi, in sostanza,
la serie numerica non è continua.
Ti segnalo un interessante thread teorico sulla questione delle chiavi
primarie artificiali sul NG comp.database.theory (titolo: "Artificial
Primary keys").
Ciao
Matteo