TL;DR Non è necessario per dichiarare una "relazione", cioè una chiave esterna (FK) da interrogare. Ma è una buona idea . Quando lo fai, un FK può fare riferimento a una chiave primaria (PK) o qualsiasi altra colonna UNICA.
PK e FK sono erroneamente chiamati "relazioni" in alcuni metodi e prodotti. Le relazioni tra le applicazioni sono rappresentate da tabelle . (Tabelle di base e risultati delle query.) PK e FK sono vincoli:indicano al DBMS che possono verificarsi solo determinate situazioni, quindi può notare quando si commettono determinati errori. Non sono relazioni, sono affermazioni vere in e per ogni stato del database e situazione dell'applicazione. Non è necessario conoscere i vincoli per aggiornare e interrogare un database.
Sai solo cosa significa ogni tabella . Le tabelle di base hanno significati dati da DBA che ti dicono cosa significano le loro righe. Le query hanno anche significati che ti dicono cosa significano le loro righe. I significati delle query vengono combinati dai significati della tabella di base in parallelo con il modo in cui i valori dei risultati vengono combinati dai valori e dalle condizioni della tabella di base.
image_tbl-- l'immagine [Id] si trova in un album chiamato [albumName], si chiama [name], è datata [dateTime] e contiene un commento [comment]album_tbl-- l'album [IDalbum] si chiama [NomeAlbum]
Non avete dichiarare eventuali PK/UNIQUE o FK! Ma è una buona idea perché in tal caso il DBMS può impedire aggiornamenti impossibili/errati. Un PK/UNIQUE dice che un valore subrow per le sue colonne deve apparire solo una volta. Un FK dice che un valore subrow per le sue colonne deve apparire come un valore subrow PK/UNIQUE nella sua tabella di riferimento. Il fatto che queste limitazioni valgano sulle tabelle di base significa che alcune limitazioni valgono sui risultati delle query. Ma i significati di quei risultati della query dipendono dalle combinazioni di tabella e condizione della query, indipendentemente da tali limitazioni. Ad esempio, se i nomi degli album sono univoci o meno,
image_tbl JOIN album_tbl USING albumName-- l'immagine [Id] si trova in un album chiamato [albumName], si chiama [name], è datata [dateTime] e contiene un commento [comment] E l'album [albumID] si chiama [albumName]
L'unico problema qui è che se i nomi degli album non sono univoci, conoscere il nome dell'album di un'immagine non ti dirà in quale album si trova; sai solo che è in un album con quel nome. D'altra parte, se i nomi degli album sono univoci, non è necessario album_tbl albumID.
Quindi, se i nomi degli album sono univoci, dichiara albumName UNIQUE in album_tbl. Quindi in image_tbl identifica l'album in base a una colonna PK/UNIQUE di album_tbl. Poiché album_id è presumibilmente presente solo allo scopo di identificare gli album, normalmente ci aspetteremmo che venga scelto. Quindi in image_tbl dichiara quella colonna come un FK che fa riferimento a album_tbl.
Gli indici PS generalmente accelerano le query a costo di un po' di tempo e spazio. Una dichiarazione di chiave primaria in una dichiarazione di tabella dichiara automaticamente un indice. È una buona idea indicizzare i set di colonne PK, UNIQUE e FK.
