Processo de Chave Estrangeira

Uma restrição de chave estrangeira na TableB tem efeito em três níveis (pelo menos).

1. Quando você INSERT INTO TableBencontra uma linha em que Student_ID não é nulo, o valor de Student_ID é procurado na TabelaA. Se não estiver lá, a inserção falhará (a linha não será inserida no banco de dados); se a inserção fizer parte de uma transação maior, a própria transação falhará. UPDATEs da TableBcoluna envolvente Student_IDse comportam de maneira semelhante (o novo valor para Student_ID é procurado na TabelaA).

2. Quando você UPDATE TableA SET Student_ID=<value>ou DELETE FROM TableAqualquer linha, o valor antigo da coluna Student_IDserá pesquisado na TabelaB. Isso incorre em alguma penalidade de desempenho (especialmente se a coluna não estiver indexada na TableB, mas o que normalmente é chamado de foreign key covering index). Se o valor for encontrado então: se a restrição FK não especificou o que fazer em UPDATE ou DELETE, o UPDATE ou INSERT falhará, porque violaria a restrição. Se o FK especificar o que fazer em UPDATE e/ou DELETE, a ação especificada será executada. Se a condição for CASCADEesta, poderá disparar UPDATES/DELETEs em tabelas referenciadas pela tabela referenciada, recursivamente.

3. Em a SELECT, uma restrição FK não terá nenhuma penalidade . Pode ter alguns efeitos benéficos para o planejador do banco de dados. A condição TableB.Student_ID IS NULL OR TableB.Student_ID in (SELECT Student_ID FROM TableA)é um fato conhecido pelo planejador, e isso pode ser usado com alguma vantagem (por exemplo, se tal condição existir em uma cláusula WHERE, ela pode ser substituída por uma constante TRUE, facilitando o processamento). Outra otimização seria converter a TableB LEFT JOIN TableA USING (Student_ID)em um INNER JOIN, se Student_ID for conhecido como não nulo, porque o planejador sabe que todas as linhas serão encontradas na TabelaA. Quanto lucro os diferentes planejadores obterão desse conhecimento dependerá fortemente da implementação.

Selecionar linhas de TableB(se TableAtambém não for especificado na cláusula FROM) não terá nenhum efeito na busca Student_IDem TableA. As restrições de chave estrangeira são aplicadas quando os dados são inseridos ou atualizados e, em seguida, conhecidos como retidos quando os dados são selecionados.

NOTA : Uma restrição FK pode especificar o que fazer quando o Student_ID pai for UPDATED ou DELETED. A sintaxe específica pode ter pequenas variações, mas é tipicamente ON {UPDATE|DELETE} {RESTRICT|NO ACTION|SET DEFAULT|SET NULL|CASCADE}. Verifique como isso funciona para PostgreSQL , MySQL , Oracle e SQL Server .

para a instrução SELECT específica sobre a qual você perguntou, não há motivo para a consulta ir para a Tabela A, pois a consulta menciona apenas a Tabela B. Pelo menos isso é verdade para qualquer produto de banco de dados com o qual trabalhei. Você não disse com qual produto de banco de dados você trabalha.

A questão sobre qual estratégia ele usaria para encontrar todas as linhas onde Books_IssueMonth = "January", isso dependeria de quais índices existem na tabela. Se houver um índice na coluna em questão, o otimizador de consulta quase certamente usará esse índice para localizar as linhas relevantes em alguns acessos ao disco. Se não houver índice na coluna em questão, a consulta teria que fazer uma varredura completa da tabela na TabelaB, o que poderia acarretar milhões de acessos ao disco se houvesse linhas suficientes na TabelaB.

A questão se torna mais interessante é você perguntar sobre um select que une TableA e TableB. Você não perguntou sobre isso. nesse caso, você precisará da coluna StudentID na TabelaB, mesmo que não a declare como FK.

No que diz respeito a ter uma coluna como StudentID que funciona como uma chave estrangeira, mas não é declarada com uma restrição FK, geralmente é uma má ideia, pelos motivos descritos na resposta de joanolo.