TL;DR Você não precisa para declarar um "relacionamento", ou seja, chave estrangeira (FK) para consulta. Mas é uma boa ideia . Ao fazer isso, um FK pode fazer referência a uma chave primária (PK) ou qualquer outra(s) coluna(s) ÚNICA(s).

PKs e FKs são erroneamente chamados de "relacionamentos" em alguns métodos e produtos. Os relacionamentos de aplicativos são representados por tabelas . (Tabelas de base e resultados de consulta.) PKs e FKs são restrições:eles informam ao DBMS que apenas certas situações podem surgir, para que ele possa perceber quando você comete certos erros. Eles não são relacionamentos, são declarações verdadeiras em cada estado de banco de dados e situação de aplicação. Você não precisa conhecer as restrições para atualizar e consultar um banco de dados.

Apenas saiba o que cada tabela significa . As tabelas base têm significados dados pelo DBA que informam o que suas linhas significam. As consultas também têm significados que informam o que suas linhas significam. Os significados da consulta são combinados a partir dos significados da tabela base em paralelo com a forma como seus valores de resultado são combinados a partir dos valores e condições da tabela base.

• image_tbl -- a imagem [Id] está em um álbum chamado [albumName], tem o nome [name], é datada de [dateTime] e tem comentário [comment]
• album_tbl -- o álbum [albumID] se chama [albumName]

Você não tem para declarar quaisquer PKs/UNIQUEs ou FKs! Mas é uma boa ideia porque então o DBMS pode não permitir atualizações impossíveis/errôneas. Um PK/UNIQUE diz que um valor de sublinha para suas colunas deve aparecer apenas uma vez. Um FK diz que um valor de sub-linha para suas colunas deve aparecer como um valor de sub-linha PK/UNIQUE em sua tabela referenciada. O fato de que essas limitações são válidas para tabelas base significa que certas limitações são válidas para os resultados da consulta. Mas os significados desses resultados de consulta são de acordo com as combinações de tabela e condição da consulta, independentemente dessas limitações. Por exemplo, se os nomes dos álbuns são únicos ou não,

• image_tbl JOIN album_tbl USING albumName -- a imagem [Id] está em um álbum chamado [albumName], tem o nome [name], é datada de [dateTime] e tem um comentário [comment] E o álbum [albumID] tem o nome [albumName]

O único problema aqui é que, se os nomes dos álbuns não forem únicos, saber o nome do álbum de uma imagem não lhe dirá em qual álbum ela está; você só sabe que está em um álbum com esse nome. Por outro lado, se os nomes dos álbuns forem exclusivos, você não precisará do album_tbl albumID.

Portanto, se os nomes dos álbuns forem exclusivos, declare albumName UNIQUE em album_tbl. Então em image_tbl identifique o álbum por alguma coluna PK/UNIQUE de album_tbl. Como album_id está presumivelmente presente apenas com o propósito de identificar álbuns, normalmente esperaríamos que fosse escolhido. Em seguida, em image_tbl, declare essa coluna como um FK referenciando album_tbl.

Índices PS geralmente aceleram a consulta ao custo de algum tempo e espaço. Uma declaração de chave primária em uma declaração de tabela declara automaticamente um índice. É uma boa ideia indexar conjuntos de colunas PK, UNIQUE e FK.