Chiave Esterna

[a***@gmail.com]

ciao a tutti
vorrei sapere a che cosa serve effettivamente mettere una Chiave Esterna (FK). Io ho un db (A2003) con 2 tabelle: tblIscritti con IDIscritto (contatore e PK) e tblDonazioni con IDDonazione (numerico) senza PK. Ad ogni iscritto appartengono + donazioni nel tempo, per cui c'è una relazione uno a molti tra i due ID con applicata l'integrità referenziale. Tutto funziona bene, inserisco i dati con una maschera Iscritti e una sottomaschera donazioni in foglio dati.
Perchè, come ho letto sul manuale di Viescas, è importante mettere una FK (in questo caso IDIscritto nella tblDonazioni)? cosa mi migliorerebbe? E poi, quale campo dovrebbe avere la PK, IDDonazione o IDIscritto? (o nessuno?)

grazie
Luciano

[Bruno Campanini]

Post by a***@gmail.com
ciao a tutti
vorrei sapere a che cosa serve effettivamente mettere una Chiave Esterna
(FK). Io ho un db (A2003) con 2 tabelle: tblIscritti con IDIscritto
(contatore e PK) e tblDonazioni con IDDonazione (numerico) senza PK. Ad ogni
iscritto appartengono + donazioni nel tempo, per cui c'è una relazione uno a
molti tra i due ID con applicata l'integrità referenziale. Tutto funziona
bene, inserisco i dati con una maschera Iscritti e una sottomaschera
donazioni in foglio dati. Perchè, come ho letto sul manuale di Viescas, è
importante mettere una FK (in questo caso IDIscritto nella tblDonazioni)?
cosa mi migliorerebbe? E poi, quale campo dovrebbe avere la PK, IDDonazione o
IDIscritto? (o nessuno?)

Che cosa sarebbe un FK? mai sentita nominare!

Metti una PK (PrimaryKey) sul PrimaryField della PrimaryTable e
definisci la relazione 1-00 col RelatedField della RelatedTable.

Il campo RelatedField potrà essere indicizzato con la modalità
duplicati consentiti SOLO SE con riferimento ad esso, indipendentemente
dalla MainTable, devi effettuare delle ricerche.
Se non devi effettuare ricerce su detto RelatedField non mettere alcun
indice: ogni indice inserito appesantisce la procedura con riflessi
negativi sulla velocità di esecuzione.

Se metti - sul RelatedField - una chiave primaria o un indice che
non consenta duplicati... addio relazione 1-00!
Ottieni, nella migliore delle ipotesi, una relazione 00-00 che non
serve a niente.
Infatti fra due campi omologhi di tablelle non relazionate hai già
una relazione 00-00.

Bruno

[Karl Donaubauer]

Ciao Bruno,

Post by Bruno Campanini
...
Che cosa sarebbe un FK? mai sentita nominare!

FK = Foreign Key = Chiave Esterna

http://it.wikipedia.org/wiki/Chiave_esterna

[Bruno Campanini]

Post by Karl Donaubauer
Ciao Bruno,

Post by Bruno Campanini
...
Che cosa sarebbe un FK? mai sentita nominare!

FK = Foreign Key = Chiave Esterna
http://it.wikipedia.org/wiki/Chiave_esterna

Sì il significato letterale l'avevo capito, ma perché
Key (chiave), caso mai è un Index (indice).

Vuoi chiamare Key un Index esterno?
Ok, e quando Index non è come lo chiami?
Io l'ho sempre chiamato RelatedField o ForeignRelatedField.

Bruno

[Karl Donaubauer]

Bruno Campanini

Post by Bruno Campanini

Post by Karl Donaubauer

Post by Bruno Campanini
...
Che cosa sarebbe un FK? mai sentita nominare!

FK = Foreign Key = Chiave Esterna
http://it.wikipedia.org/wiki/Chiave_esterna

Sì il significato letterale l'avevo capito, ma perché
Key (chiave), caso mai è un Index (indice).

Un FK è un Key o chiave perché fa parte della relazione
nella tabella secondaria (o anche nella stessa tabella).

L'index sul campo non è una premessa e cambia niente
in rispetto al ruolo di un FK ma è solo un supplemento
che si fa (o qui che fa Access) per migliorare la prestazione.

Post by Bruno Campanini
Vuoi chiamare Key un Index esterno?
Ok, e quando Index non è come lo chiami?
Io l'ho sempre chiamato RelatedField o ForeignRelatedField.

"Index" è un altra cosa.
"Key" è la nomenclatura ufficiale per questo ruolo in una relazione.
Certo si puo sempre creare la sua nomenclatura personale. ;-)

[Karl Donaubauer]

Post by Karl Donaubauer

Post by Bruno Campanini
...
Sì il significato letterale l'avevo capito, ma perché
Key (chiave), caso mai è un Index (indice).

Un FK è un Key o chiave perché fa parte della relazione
nella tabella secondaria (o anche nella stessa tabella).
L'index sul campo non è una premessa e cambia niente
in rispetto al ruolo di un FK ma è solo un supplemento
che si fa (o qui che fa Access) per migliorare la prestazione.

Post by Bruno Campanini
Vuoi chiamare Key un Index esterno?
Ok, e quando Index non è come lo chiami?
Io l'ho sempre chiamato RelatedField o ForeignRelatedField.

"Index" è un altra cosa.
"Key" è la nomenclatura ufficiale per questo ruolo in una relazione.
Certo si puo sempre creare la sua nomenclatura personale. ;-)

A proposito... di FK è un ruolo (ovvero "constraint").
Si deve aggiungere che un foreign key puo essere composto
da 1 solo campo ma anche da 2 o più = n campi o foreign
key fields/columns. In inglese e tedesco (Fremdschlüsselfeld)
si dice così, in italiano non sono sicuro.

[Karl Donaubauer]

Post by a***@gmail.com
vorrei sapere a che cosa serve effettivamente mettere una Chiave
Esterna (FK). Io ho un db (A2003) con 2 tabelle: tblIscritti con
IDIscritto (contatore e PK) e tblDonazioni con IDDonazione (numerico)
senza PK. Ad ogni iscritto appartengono + donazioni nel tempo, per
cui c'è una relazione uno a molti tra i due ID con applicata
l'integrità referenziale. Tutto funziona bene, inserisco i dati con
una maschera Iscritti e una sottomaschera donazioni in foglio dati.
Perchè, come ho letto sul manuale di Viescas, è importante mettere
una FK (in questo caso IDIscritto nella tblDonazioni)? cosa mi
migliorerebbe? E poi, quale campo dovrebbe avere la PK,
IDDonazione o IDIscritto? (o nessuno?)

FK vuol dire un campo che nella seconda tabella contiene
dati della prima tabella per collegare le due tabelle.
Vuol dire che hai già messo un FK: il campo IDDonazione.

Del resto nel momento quando hai creato la relazione, Access
automaticamente ha aggiunto un index sul campo del FK, cioè
IDDonazione per migliorare la prestazione.

Però ci sono due errori nella tua costellazione:
1. La tabella tblDonazioni non ha un PK.
2. Con "Id..." hai usato la denominazione classica per il
campo univoco e PK come FK. Il modo giusto sarebbe:

Nella tabella tblDonazioni c'è un campo IDDonazione
del tipo contatore impostato come PK della tabella.

Sempre nella tabella tblDonazioni c'è un campo
IDIscritto (o FKIDIscritto) del tipo numerico (Long).
Su questo campo è impostato la relazione con tblIscritti.

[Bruno Campanini]

Post by Karl Donaubauer
FK vuol dire un campo che nella seconda tabella contiene
dati della prima tabella per collegare le due tabelle.
Vuol dire che hai già messo un FK: il campo IDDonazione.
Del resto nel momento quando hai creato la relazione, Access
automaticamente ha aggiunto un index sul campo del FK, cioè
IDDonazione per migliorare la prestazione.

Quando mai?
Access non pone alcun indice nel RelatedField (FK) della RelatedTable.
Lo poni tu solo se ti serve.
Poiché inserire un indice quando non serve peggiora soltanto
le prestazioni.

Bruno

[Karl Donaubauer]

Post by Bruno Campanini

Post by Karl Donaubauer
...
Del resto nel momento quando hai creato la relazione, Access
automaticamente ha aggiunto un index sul campo del FK, cioè
IDDonazione per migliorare la prestazione.

Quando mai?
Access non pone alcun indice nel RelatedField (FK) della
RelatedTable. Lo poni tu solo se ti serve.

Sei sicuro?

Post by Bruno Campanini
Poiché inserire un indice quando non serve peggiora soltanto
le prestazioni.

Un indice sul FK serve in 99% dei casi.
Con questa convinzione la MS ha incluso l'indice automatico
in Access.

Fai due piccole prove con una qualsiasi versione di Access:

1. La versione brava

Creati una tabella A con campo IdA, tipo contatore e PK
e una tabella B con campo IdA, tipo long, senza indice.

Crea una relazione senza RI tra le due tabelle.
Nella finestra degli indici di B controlla che Access ha creato
un indice sul campo IdA.

Questa funziona solo se i due campi della relazione hanno
lo stesso nome. Al contrario del

2. La versione cattiva

Togli la relazione e togli l'indice nella tabella B.
Poi imposta una relazione tra le tabelle con RI attivata.
Nella finestra degli indici di B controlla che non vedi
nessun indice. Tutto perfetto, quasi.
Esegui questo codice:

Dim db As DAO.Database
Dim tdf As DAO.TableDef
Dim idx As DAO.Index

Set db = CurrentDb
Set tdf = db.TableDefs("B")

For Each idx In tdf.Indexes
MsgBox idx.Name
Next

e stupisciti se lo vedi per la prima volta.

Siccome non si vede l'indice nella finestra dei indici
della tabella e molta gente non sa del meccanismo
nuotiamo in un mare di indici duplicati.

[Bruno Campanini]

Post by Karl Donaubauer
Sei sicuro?

Io non sono addentro alle segrete cose di MS e apprendo solo ora
dell'automatico inserimento di un indice (invisibile) sulla
RelatedTable.
Tale indice viene denominato MainTRelatedT (se MainT e RelatedT sono
i nomi delle due tabelle) e la Property Foreign dichiarata TRUE.

Se poi l'utente (inconsapevole del fatto) ne aggiunge un altro,
questo assume la denominazione del campo e la Property Foreign
dichiarata FALSE.

I due indici avranno funzioni diverse? si spera di sì...
Altrimenti si rischia davvero di navigare in un mare di indici.

Io comunque, normalmente, nulla aggiungo in fatto di indici
alla related table.

Bruno

[Pablitomf]

Post by a***@gmail.com
grazie
Luciano

la chiave esterna altro non e' che un campo sulla tabella secondaria (che
non sia il suo PK che ci vuole cmq), che faccia da relazione al campo PK
della tabella primaria...