[MySQL] Foreign Key quali vantaggi porta?

[lore_83]

Ciao.
Sto imparando da poco ad usare il database mysql.
Vorrei sapere quali sono i vantaggi/svantaggi nel creare le foreign keys in una tabella, poiché non mi è chiaro il loro utilizzo.

esempio:

TABELLA CITTA

ID_CITTA
NOME
ID_NAZ
FOREIGN KEY (ID_NAZ) REFERENCES NAZIONE (ID_NAZIONE)

TABELLA NAZIONE

ID_NAZIONE
NOME

L'esempio è calzante (sintassi a parte)?
Quali vantaggi/svantaggi ho?
Le ricerche con INNER JOIN non sono indipendenti dalla presenza delle F. Keys?

Grazie e ciao.

[gugoXX]

Non ci sono vantaggi prestazionali.
E' parte dei vincoli di disegno. Se imponi quella FK tra citta' e nazione sarai SICURO sempre che ogni citta' apparterra' ad una nazione, e potrai permetterti di scrivere le query di conseguenza.
P.Es. potrai usare una INNER JOIN. Altrimenti potresti essere costretto ad usare una OUTER JOIN, proprio perche' non saresti sicuro di trovare sempre una nazione a capo di una citta'.
I vincoli e' bene che siano gestiti a livello di database. Poi sara' cura delle tue GUI, dei tuoi programmi o di quanto'altro fare in modo che non vengano violati. Ma se qualora mai venissero violati (errore di programmazione), il database rifiuterebbe le istruzioni che non li rispettano mantenendo il dati in uno stato di consistenza, che altrimenti verrebbe violata e neppure te ne accorgeresti.

Ci sono altri vincoli, non solo le FK.
Tra i principali ci sono anche i "NOT NULL" e gli "UNIQUE"

[lore_83]

Ciao.

Si tratta quindi di una semplice istruzione che garantisce la relazione ad ogni città con un ed un solo record della tabella delle nazioni ed automaticamente ID_NAZ è NOT NULL.

[gugoXX]

Originariamente inviato da lore_83

Ciao.

Si tratta quindi di una semplice istruzione che garantisce la relazione ad ogni città con un ed un solo record della tabella delle nazioni ed automaticamente ID_NAZ è NOT NULL.

non e' automaticamente NOT NULL, meglio forzarglielo se ti serve.

[shinya]

Quoto tutto quanto detto da gugoXX, in più ti consiglio anche di mettere un indice sulle FK. Non so con mysql (in particolare con innoDB, immagino tu stia utilizzando quel meccanismo e non MyISAM che credo manco le supporti le FK...lol!), ma in oracle gli indici sulle fk servono per evitare il table lock e usare invece il row lock...se mi ricordo bene...

[lore_83]

...in più ti consiglio anche di mettere un indice sulle FK...

Cioè mettere INDEX() su ID_NAZIONE nella tabella NAZIONI?

...gli indici sulle fk servono per evitare il table lock e usare invece il row lock...

E per uno che non sa nemmeno cosa sia questo problema?

PS: se inserissi un valore ID_NAZ non esistente in ID_NAZIONE il db mi darebbe errore, corretto?

Grazie comunque, davvero rapidi ed utili.

[shinya]

Originariamente inviato da lore_83

Cioè mettere INDEX() su ID_NAZIONE nella tabella NAZIONI?

No, quella è la PK della tabella NAZIONI e l'indice unique dovrebbe venir da sè (spero! comunque ci vuole.)

Io dico l'indice su ID_NAZ nella tabella CITTA.

E per uno che non sa nemmeno cosa sia questo problema?

Devi guardare sul manuale...non conosco MySQL cosi a fondo. Ma se hai un numero di righe esigue, non è un grosso problema quello del lock a livello di riga o di tabella.

PS: se inserissi un valore ID_NAZ non esistente in ID_NAZIONE il db mi darebbe errore, corretto?

Grazie comunque, davvero rapidi ed utili.

Si esatto.

[dupa]

Originariamente inviato da gugoXX

Non ci sono vantaggi prestazionali.
E' parte dei vincoli di disegno. Se imponi quella FK tra citta' e nazione sarai SICURO sempre che ogni citta' apparterra' ad una nazione, e potrai permetterti di scrivere le query di conseguenza.
P.Es. potrai usare una INNER JOIN. Altrimenti potresti essere costretto ad usare una OUTER JOIN, proprio perche' non saresti sicuro di trovare sempre una nazione a capo di una citta'.
I vincoli e' bene che siano gestiti a livello di database. Poi sara' cura delle tue

Non mi pare sia come tu dici.
Una colonna FK potrebbe essere tranquillamente NULL, quind iil tuo discorso sulle JOIN cade.

Cmq i grossi vantaggi delle FK sono le ON UPDATE, ON DELETE.

[cdimauro]

Originariamente inviato da gugoXX

Non ci sono vantaggi prestazionali.
E' parte dei vincoli di disegno. Se imponi quella FK tra citta' e nazione sarai SICURO sempre che ogni citta' apparterra' ad una nazione, e potrai permetterti di scrivere le query di conseguenza.
P.Es. potrai usare una INNER JOIN. Altrimenti potresti essere costretto ad usare una OUTER JOIN, proprio perche' non saresti sicuro di trovare sempre una nazione a capo di una citta'.
I vincoli e' bene che siano gestiti a livello di database. Poi sara' cura delle tue GUI, dei tuoi programmi o di quanto'altro fare in modo che non vengano violati. Ma se qualora mai venissero violati (errore di programmazione), il database rifiuterebbe le istruzioni che non li rispettano mantenendo il dati in uno stato di consistenza, che altrimenti verrebbe violata e neppure te ne accorgeresti.

Ci sono altri vincoli, non solo le FK.
Tra i principali ci sono anche i "NOT NULL" e gli "UNIQUE"

Concordo: l'integrità referenziale serve a mantenere consistenti (almeno per questa parte) i dati. E visto che i database devono gestire dati...

Originariamente inviato da shinya

Quoto tutto quanto detto da gugoXX, in più ti consiglio anche di mettere un indice sulle FK. Non so con mysql (in particolare con innoDB, immagino tu stia utilizzando quel meccanismo e non MyISAM che credo manco le supporti le FK...lol!), ma in oracle gli indici sulle fk servono per evitare il table lock e usare invece il row lock...se mi ricordo bene...

Mumble. Strano. Indicando un constraint di FOREING KEY generalmente viene sempre creato un indice per il campo che ne fa uso.

Originariamente inviato da dupa

Non mi pare sia come tu dici.
Una colonna FK potrebbe essere tranquillamente NULL, quind iil tuo discorso sulle JOIN cade.

Cmq i grossi vantaggi delle FK sono le ON UPDATE, ON DELETE.

Il discorso fondamentale è che i dati siano consistenti, e quanto scritto da "gugo" va benissimo anche nel caso in cui la colonna in oggetto accetti NULL come "valore".

E' chiaro, comunque, che con un valore NULL la JOIN non potrà eseguire il "match".