fk_animais_usuario não é um atributo, é uma declaração de restrição de chave estrangeira. Quando você adiciona essa constraint à tabela, o próprio SGBD garante que o campo id_user será preenchido com um valor que exista na tabela usuario. Caso contrário, você poderia colocar qualquer valor no campo, o que tornaria o relacionamento inconsistente.
N
Nathaliempg
Ok. Então posso concluir que, se não usarmos esta declaração de restrição pode haver erro? Ou seja, o dado que está na tabela usuario(em iduser) não terá nenhuma correspondência com a chave estrangeira(iduser) da tabela animais, é isso?
Como disse, vi que em alguns códigos não é usada esta restrição. E ao que me parece, não ocorre erro. Ainda não fiz nenhum código utilizando isso, o que quero é entender para que serve a restrição constraint. Já li muita definição na net, mas ainda não consegui entendê-la totalmente. Se puder me ajudar, agradeço. Nathalie.
R
Solucao aceita
rmendes08
Mas é justamente esse o problema. Sem a restrição o banco não dispara erro. Veja só, suponha que a tabela de usuários tem os seguintes registros:
id_usuario | nome-----------------
1 | João
2 | José
3 | Maria
se você não declarar que o campo id_usuario na tabela animais é uma chave estrangeira, isto é, se você não criar a constraint então o campo animais.id_usuario aceitará qualquer valor, porém, se você criar a constraint, ao tentar preencher o campo com algum valor que não esteja na tabela de usuário, ou seja, qualquer coisa diferente de 1,2 ou 3 o banco vai disparar erro e não vai deixar a atualização acontecer, entendeu ?
N
Nathaliempg
mendes08, muito obrigada, agora entendi. Então, se não usar a constraint, o banco não avisa sobre o erro, mas os dados da tabela podem ficar errados, inconsistentes. Sua explicação foi bem objetiva.
Só mais uma dúvida: esta restrição é o mesmo que index? Pelo que entendi, o index ajuda na procura pelos registros. Obrigada, Nathalie
R
rmendes08
Isso mesmo, você entendeu. Agora, index, ou índice é algo diferente de restrição de chave estrangeira (foreing key constraint). Como você disse, os índice servem para melhorar o desempenho na busca por registros. Quando você cria um índice sobre um campo o BD cria uma árvore B com os valores do campo, de forma que ao consultar a tabela por este campo, serão executadas buscas binárias ao invés de buscas lineares.
N
Nathaliempg
Ou seja, é sempre bom definir o index. mendes08 muito obrigada mesmo. Abraços, Nathalie
R
rmendes08
Sim. Mas veja bem, somente crie índices que realmente serão usados. É errado por exemplo criar índices para todas as colunas de uma tabela, pois nem todas serão usadas para buscas. E se por um lado índices deixam as buscas mais rápidas, inserções, exclusões e atualizações podem ficar comprometidas se a tabela tiver muitos índices, pois os índices tem que ser atualizados a cada nova atualização na tabela.
N
Nathaliempg
O correto então seria criar índices apenas para as chaves primárias de cada tabela?
R
rmendes08
Não, de maneira geral, os BDs já criam índices automaticamente para as chaves primárias. Mas por exemplo, suponha que você tenha a seguinte tabela:
Cliente(id, cpf, nome, data_nascimento)
Id é chave primária, portanto já tem índice
cpf é um bom campo para se criar um índice. Além de ser único para cada cliente é comum que sistemas comerciais suportem busca pelo cpf.
Enfim, uma vez que você entendeu o que são índices e para que servem, você tem que analisar cada caso. Não dá pra elaborar uma regra geral. Você tem que refletir quais campos serão usados nas buscas, e com qual frequência para então decidir qual será a estrutura dos índices.
N
Nathaliempg
Entendido, sem dúvida nenhuma. Só criar índices se isso for realmente agilizar as buscas. Mais uma vez, muito obrigado. Abraços, Nathalie.
